From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932499AbcLIDJx convert rfc822-to-8bit (ORCPT ); Thu, 8 Dec 2016 22:09:53 -0500 Received: from mga09.intel.com ([134.134.136.24]:8976 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932170AbcLIDJv (ORCPT ); Thu, 8 Dec 2016 22:09:51 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,322,1477983600"; d="scan'208";a="1079517870" From: "Li, Liang Z" To: "Hansen, Dave" , David Hildenbrand , "kvm@vger.kernel.org" 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" , "kirill.shutemov@linux.intel.com" , "pbonzini@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "dgilbert@redhat.com" Subject: RE: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Thread-Topic: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Thread-Index: AQHSSufi4SQjg1m8CEK5jUmkErPNiaD6HPWAgAJj94D//6HsgIAC0afA Date: Fri, 9 Dec 2016 03:09:47 +0000 Message-ID: References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjNmZDg2ZjctNjM3OS00NDY4LWI4OTgtZGU4MDlhMjg5M2E2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InpIRWdSRGh4M1JoeDZTSHMzSlROc2F3eThQM0NMYk96MkdKZCt6S0RCZFU9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating > & fast live migration > > On 12/07/2016 05:35 AM, Li, Liang Z wrote: > >> Am 30.11.2016 um 09:43 schrieb Liang Li: > >> IOW in real examples, do we have really large consecutive areas or > >> are all pages just completely distributed over our memory? > > > > The buddy system of Linux kernel memory management shows there > should > > be quite a lot of consecutive pages as long as there are a portion of > > free memory in the guest. > ... > > If all pages just completely distributed over our memory, it means the > > memory fragmentation is very serious, the kernel has the mechanism to > > avoid this happened. > > While it is correct that the kernel has anti-fragmentation mechanisms, I don't > think it invalidates the question as to whether a bitmap would be too sparse > to be effective. > > > In the other hand, the inflating should not happen at this time > > because the guest is almost 'out of memory'. > > I don't think this is correct. Most systems try to run with relatively little free > memory all the time, using the bulk of it as page cache. We have no reason > to expect that ballooning will only occur when there is lots of actual free > memory and that it will not occur when that same memory is in use as page > cache. > Yes. > In these patches, you're effectively still sending pfns. You're just sending > one pfn per high-order page which is giving a really nice speedup. IMNHO, > you're avoiding doing a real bitmap because creating a bitmap means either > have a really big bitmap, or you would have to do some sorting (or multiple > passes) of the free lists before populating a smaller bitmap. > > Like David, I would still like to see some data on whether the choice between > bitmaps and pfn lists is ever clearly in favor of bitmaps. You haven't > convinced me, at least, that the data isn't even worth collecting. I will try to get some data with the real workload and share it with your guys. Thanks! Liang From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Li, Liang Z" Subject: RE: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Date: Fri, 9 Dec 2016 03:09:47 +0000 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" Content-Transfer-Encoding: quoted-printable 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" , "kirill.shutemov@linux.intel.com" , "pbonzini@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "dgilbert@redhat.com" To: "Hansen, Dave" , David Hildenbrand , "kvm@vger.kernel.org" Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: Content-Language: en-US List-Id: kvm.vger.kernel.org > Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inf= lating > & fast live migration >=20 > On 12/07/2016 05:35 AM, Li, Liang Z wrote: > >> Am 30.11.2016 um 09:43 schrieb Liang Li: > >> IOW in real examples, do we have really large consecutive areas or > >> are all pages just completely distributed over our memory? > > > > The buddy system of Linux kernel memory management shows there > should > > be quite a lot of consecutive pages as long as there are a portion of > > free memory in the guest. > ... > > If all pages just completely distributed over our memory, it means the > > memory fragmentation is very serious, the kernel has the mechanism to > > avoid this happened. >=20 > While it is correct that the kernel has anti-fragmentation mechanisms, I = don't > think it invalidates the question as to whether a bitmap would be too spa= rse > to be effective. >=20 > > In the other hand, the inflating should not happen at this time > > because the guest is almost 'out of memory'. >=20 > I don't think this is correct. Most systems try to run with relatively l= ittle free > memory all the time, using the bulk of it as page cache. We have no reas= on > to expect that ballooning will only occur when there is lots of actual fr= ee > memory and that it will not occur when that same memory is in use as page > cache. >=20 Yes. > In these patches, you're effectively still sending pfns. You're just sen= ding > one pfn per high-order page which is giving a really nice speedup. IMNHO= , > you're avoiding doing a real bitmap because creating a bitmap means eithe= r > have a really big bitmap, or you would have to do some sorting (or multip= le > passes) of the free lists before populating a smaller bitmap. >=20 > Like David, I would still like to see some data on whether the choice bet= ween > bitmaps and pfn lists is ever clearly in favor of bitmaps. You haven't > convinced me, at least, that the data isn't even worth collecting. I will try to get some data with the real workload and share it with your g= uys. Thanks! Liang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id E07F36B0069 for ; Thu, 8 Dec 2016 22:09:51 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id q10so11875711pgq.7 for ; Thu, 08 Dec 2016 19:09:51 -0800 (PST) Received: from mga04.intel.com (mga04.intel.com. [192.55.52.120]) by mx.google.com with ESMTPS id 129si31531510pfx.1.2016.12.08.19.09.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Dec 2016 19:09:50 -0800 (PST) From: "Li, Liang Z" Subject: RE: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Date: Fri, 9 Dec 2016 03:09:47 +0000 Message-ID: References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: "Hansen, Dave" , David Hildenbrand , "kvm@vger.kernel.org" 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" , "kirill.shutemov@linux.intel.com" , "pbonzini@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "dgilbert@redhat.com" > Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inf= lating > & fast live migration >=20 > On 12/07/2016 05:35 AM, Li, Liang Z wrote: > >> Am 30.11.2016 um 09:43 schrieb Liang Li: > >> IOW in real examples, do we have really large consecutive areas or > >> are all pages just completely distributed over our memory? > > > > The buddy system of Linux kernel memory management shows there > should > > be quite a lot of consecutive pages as long as there are a portion of > > free memory in the guest. > ... > > If all pages just completely distributed over our memory, it means the > > memory fragmentation is very serious, the kernel has the mechanism to > > avoid this happened. >=20 > While it is correct that the kernel has anti-fragmentation mechanisms, I = don't > think it invalidates the question as to whether a bitmap would be too spa= rse > to be effective. >=20 > > In the other hand, the inflating should not happen at this time > > because the guest is almost 'out of memory'. >=20 > I don't think this is correct. Most systems try to run with relatively l= ittle free > memory all the time, using the bulk of it as page cache. We have no reas= on > to expect that ballooning will only occur when there is lots of actual fr= ee > memory and that it will not occur when that same memory is in use as page > cache. >=20 Yes. > In these patches, you're effectively still sending pfns. You're just sen= ding > one pfn per high-order page which is giving a really nice speedup. IMNHO= , > you're avoiding doing a real bitmap because creating a bitmap means eithe= r > have a really big bitmap, or you would have to do some sorting (or multip= le > passes) of the free lists before populating a smaller bitmap. >=20 > Like David, I would still like to see some data on whether the choice bet= ween > bitmaps and pfn lists is ever clearly in favor of bitmaps. You haven't > convinced me, at least, that the data isn't even worth collecting. I will try to get some data with the real workload and share it with your g= uys. Thanks! Liang -- 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]:43306) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFBZN-0005Bi-L0 for qemu-devel@nongnu.org; Thu, 08 Dec 2016 22:09:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFBZK-0005Pn-H0 for qemu-devel@nongnu.org; Thu, 08 Dec 2016 22:09:57 -0500 Received: from mga06.intel.com ([134.134.136.31]:65444) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cFBZK-0005OP-52 for qemu-devel@nongnu.org; Thu, 08 Dec 2016 22:09:54 -0500 From: "Li, Liang Z" Date: Fri, 9 Dec 2016 03:09:47 +0000 Message-ID: References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: "Hansen, Dave" , David Hildenbrand , "kvm@vger.kernel.org" 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" , "kirill.shutemov@linux.intel.com" , "pbonzini@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "dgilbert@redhat.com" > Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inf= lating > & fast live migration >=20 > On 12/07/2016 05:35 AM, Li, Liang Z wrote: > >> Am 30.11.2016 um 09:43 schrieb Liang Li: > >> IOW in real examples, do we have really large consecutive areas or > >> are all pages just completely distributed over our memory? > > > > The buddy system of Linux kernel memory management shows there > should > > be quite a lot of consecutive pages as long as there are a portion of > > free memory in the guest. > ... > > If all pages just completely distributed over our memory, it means the > > memory fragmentation is very serious, the kernel has the mechanism to > > avoid this happened. >=20 > While it is correct that the kernel has anti-fragmentation mechanisms, I = don't > think it invalidates the question as to whether a bitmap would be too spa= rse > to be effective. >=20 > > In the other hand, the inflating should not happen at this time > > because the guest is almost 'out of memory'. >=20 > I don't think this is correct. Most systems try to run with relatively l= ittle free > memory all the time, using the bulk of it as page cache. We have no reas= on > to expect that ballooning will only occur when there is lots of actual fr= ee > memory and that it will not occur when that same memory is in use as page > cache. >=20 Yes. > In these patches, you're effectively still sending pfns. You're just sen= ding > one pfn per high-order page which is giving a really nice speedup. IMNHO= , > you're avoiding doing a real bitmap because creating a bitmap means eithe= r > have a really big bitmap, or you would have to do some sorting (or multip= le > passes) of the free lists before populating a smaller bitmap. >=20 > Like David, I would still like to see some data on whether the choice bet= ween > bitmaps and pfn lists is ever clearly in favor of bitmaps. You haven't > convinced me, at least, that the data isn't even worth collecting. I will try to get some data with the real workload and share it with your g= uys. Thanks! Liang