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