From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753012AbcLFIk5 (ORCPT ); Tue, 6 Dec 2016 03:40:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59690 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752923AbcLFIkx (ORCPT ); Tue, 6 Dec 2016 03:40:53 -0500 Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration To: Liang Li , kvm@vger.kernel.org References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> Cc: virtio-dev@lists.oasis-open.org, mhocko@suse.com, mst@redhat.com, dave.hansen@intel.com, qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kirill.shutemov@linux.intel.com, pbonzini@redhat.com, akpm@linux-foundation.org, virtualization@lists.linux-foundation.org, dgilbert@redhat.com From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Tue, 6 Dec 2016 09:40:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 06 Dec 2016 08:40:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 30.11.2016 um 09:43 schrieb Liang Li: > This patch set contains two parts of changes to the virtio-balloon. > > One is the change for speeding up the inflating & deflating process, > the main idea of this optimization is to use bitmap to send the page > information to host instead of the PFNs, to reduce the overhead of > virtio data transmission, address translation and madvise(). This can > help to improve the performance by about 85%. Do you have some statistics/some rough feeling how many consecutive bits are usually set in the bitmaps? Is it really just purely random or is there some granularity that is usually consecutive? IOW in real examples, do we have really large consecutive areas or are all pages just completely distributed over our memory? Thanks! -- David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Date: Tue, 6 Dec 2016 09:40:47 +0100 Message-ID: References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Cc: virtio-dev@lists.oasis-open.org, mhocko@suse.com, mst@redhat.com, qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, dave.hansen@intel.com, dgilbert@redhat.com, pbonzini@redhat.com, akpm@linux-foundation.org, virtualization@lists.linux-foundation.org, kirill.shutemov@linux.intel.com To: Liang Li , kvm@vger.kernel.org Return-path: In-Reply-To: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: kvm.vger.kernel.org Am 30.11.2016 um 09:43 schrieb Liang Li: > This patch set contains two parts of changes to the virtio-balloon. > > One is the change for speeding up the inflating & deflating process, > the main idea of this optimization is to use bitmap to send the page > information to host instead of the PFNs, to reduce the overhead of > virtio data transmission, address translation and madvise(). This can > help to improve the performance by about 85%. Do you have some statistics/some rough feeling how many consecutive bits are usually set in the bitmaps? Is it really just purely random or is there some granularity that is usually consecutive? IOW in real examples, do we have really large consecutive areas or are all pages just completely distributed over our memory? Thanks! -- David From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f199.google.com (mail-qt0-f199.google.com [209.85.216.199]) by kanga.kvack.org (Postfix) with ESMTP id 17EC86B025E for ; Tue, 6 Dec 2016 03:40:55 -0500 (EST) Received: by mail-qt0-f199.google.com with SMTP id w39so238491968qtw.0 for ; Tue, 06 Dec 2016 00:40:55 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id v199si11166011qkb.327.2016.12.06.00.40.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 00:40:54 -0800 (PST) Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> From: David Hildenbrand Message-ID: Date: Tue, 6 Dec 2016 09:40:47 +0100 MIME-Version: 1.0 In-Reply-To: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Liang Li , kvm@vger.kernel.org Cc: virtio-dev@lists.oasis-open.org, mhocko@suse.com, mst@redhat.com, dave.hansen@intel.com, qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kirill.shutemov@linux.intel.com, pbonzini@redhat.com, akpm@linux-foundation.org, virtualization@lists.linux-foundation.org, dgilbert@redhat.com Am 30.11.2016 um 09:43 schrieb Liang Li: > This patch set contains two parts of changes to the virtio-balloon. > > One is the change for speeding up the inflating & deflating process, > the main idea of this optimization is to use bitmap to send the page > information to host instead of the PFNs, to reduce the overhead of > virtio data transmission, address translation and madvise(). This can > help to improve the performance by about 85%. Do you have some statistics/some rough feeling how many consecutive bits are usually set in the bitmaps? Is it really just purely random or is there some granularity that is usually consecutive? IOW in real examples, do we have really large consecutive areas or are all pages just completely distributed over our memory? Thanks! -- David -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEBJ4-0005zQ-1G for qemu-devel@nongnu.org; Tue, 06 Dec 2016 03:40:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cEBJ0-0004Oe-Vx for qemu-devel@nongnu.org; Tue, 06 Dec 2016 03:40:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57792) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cEBJ0-0004OH-QD for qemu-devel@nongnu.org; Tue, 06 Dec 2016 03:40:54 -0500 References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> From: David Hildenbrand Message-ID: Date: Tue, 6 Dec 2016 09:40:47 +0100 MIME-Version: 1.0 In-Reply-To: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liang Li , kvm@vger.kernel.org Cc: virtio-dev@lists.oasis-open.org, mhocko@suse.com, mst@redhat.com, dave.hansen@intel.com, qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kirill.shutemov@linux.intel.com, pbonzini@redhat.com, akpm@linux-foundation.org, virtualization@lists.linux-foundation.org, dgilbert@redhat.com Am 30.11.2016 um 09:43 schrieb Liang Li: > This patch set contains two parts of changes to the virtio-balloon. > > One is the change for speeding up the inflating & deflating process, > the main idea of this optimization is to use bitmap to send the page > information to host instead of the PFNs, to reduce the overhead of > virtio data transmission, address translation and madvise(). This can > help to improve the performance by about 85%. Do you have some statistics/some rough feeling how many consecutive bits are usually set in the bitmaps? Is it really just purely random or is there some granularity that is usually consecutive? IOW in real examples, do we have really large consecutive areas or are all pages just completely distributed over our memory? Thanks! -- David