From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934966AbcJ0AvT convert rfc822-to-8bit (ORCPT ); Wed, 26 Oct 2016 20:51:19 -0400 Received: from mga09.intel.com ([134.134.136.24]:45169 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932388AbcJ0AvR (ORCPT ); Wed, 26 Oct 2016 20:51:17 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,551,1473145200"; d="scan'208";a="24509546" From: "Li, Liang Z" To: "Hansen, Dave" , "mst@redhat.com" CC: "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "linux-mm@kvack.org" , "virtio-dev@lists.oasis-open.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "quintela@redhat.com" , "dgilbert@redhat.com" , "pbonzini@redhat.com" , "cornelia.huck@de.ibm.com" , "amit.shah@redhat.com" Subject: RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration Thread-Topic: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration Thread-Index: AQHSK2WJC1hKfNkP2EaN2boMpmMvBaCyo0uAgAfeEICAAApwgIAA8aJg Date: Thu, 27 Oct 2016 00:51:13 +0000 Message-ID: References: <1477031080-12616-1-git-send-email-liang.z.li@intel.com> <580A4F81.60201@intel.com> <5810F1C7.4060807@intel.com> In-Reply-To: <5810F1C7.4060807@intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzBkYTE0Y2EtMWY1MC00NzZmLTk0ZWMtZjA4ZmYyZmNkYWIwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjdTcm9zZzA4c09KS3FoVE41cUppSUFNbVZwVVdIRU5QeThncTg0a1V0NEE9In0= 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 > On 10/26/2016 03:06 AM, Li, Liang Z wrote: > > I am working on Dave's new bitmap schema, I have finished the part of > > getting the 'hybrid scheme bitmap' and found the complexity was more > > than I expected. The main issue is more memory is required to save the > > 'hybrid scheme bitmap' beside that used to save the raw page bitmap, > > for the worst case, the memory required is 3 times than that in the > > previous implementation. > > Really? Could you please describe the scenario where this occurs? > > I am wondering if I should continue, as an alternative solution, how > > about using PFNs array when inflating/deflating only a few pages? > > Things will be much more simple. > > Yes, using pfn lists is more efficient than using bitmaps for sparse bitmaps. > Yes, there will be cases where it is preferable to just use pfn lists vs. any kind > of bitmap. > > But, what does it matter? At least with your current scheme where we go > out and collect get_unused_pages(), we do the allocation up front. The > space efficiency doesn't matter at all for small sizes since we do the constant- > size allocation *anyway*. > > I'm also pretty sure you can pack the pfn and page order into a single 64-bit > word and have no bitmap for a given record. That would make it pack just as > well as the old pfns alone. Right? Yes, thanks for reminding, I am using 128 bit now, I will change it to 64 bit. Let me finish the v4 first. Thanks! Liang From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Li, Liang Z" Subject: RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration Date: Thu, 27 Oct 2016 00:51:13 +0000 Message-ID: References: <1477031080-12616-1-git-send-email-liang.z.li@intel.com> <580A4F81.60201@intel.com> <5810F1C7.4060807@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "virtio-dev@lists.oasis-open.org" , "kvm@vger.kernel.org" , "amit.shah@redhat.com" , "qemu-devel@nongnu.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "pbonzini@redhat.com" , "virtualization@lists.linux-foundation.org" , "dgilbert@redhat.com" To: "Hansen, Dave" , "mst@redhat.com" Return-path: In-Reply-To: <5810F1C7.4060807@intel.com> Content-Language: en-US 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 > On 10/26/2016 03:06 AM, Li, Liang Z wrote: > > I am working on Dave's new bitmap schema, I have finished the part of > > getting the 'hybrid scheme bitmap' and found the complexity was more > > than I expected. The main issue is more memory is required to save the > > 'hybrid scheme bitmap' beside that used to save the raw page bitmap, > > for the worst case, the memory required is 3 times than that in the > > previous implementation. > > Really? Could you please describe the scenario where this occurs? > > I am wondering if I should continue, as an alternative solution, how > > about using PFNs array when inflating/deflating only a few pages? > > Things will be much more simple. > > Yes, using pfn lists is more efficient than using bitmaps for sparse bitmaps. > Yes, there will be cases where it is preferable to just use pfn lists vs. any kind > of bitmap. > > But, what does it matter? At least with your current scheme where we go > out and collect get_unused_pages(), we do the allocation up front. The > space efficiency doesn't matter at all for small sizes since we do the constant- > size allocation *anyway*. > > I'm also pretty sure you can pack the pfn and page order into a single 64-bit > word and have no bitmap for a given record. That would make it pack just as > well as the old pfns alone. Right? Yes, thanks for reminding, I am using 128 bit now, I will change it to 64 bit. Let me finish the v4 first. Thanks! Liang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f69.google.com (mail-pa0-f69.google.com [209.85.220.69]) by kanga.kvack.org (Postfix) with ESMTP id 59EAE6B027A for ; Wed, 26 Oct 2016 20:51:17 -0400 (EDT) Received: by mail-pa0-f69.google.com with SMTP id r13so11831246pag.1 for ; Wed, 26 Oct 2016 17:51:17 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com. [134.134.136.24]) by mx.google.com with ESMTPS id d76si5194066pga.220.2016.10.26.17.51.16 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 26 Oct 2016 17:51:16 -0700 (PDT) From: "Li, Liang Z" Subject: RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration Date: Thu, 27 Oct 2016 00:51:13 +0000 Message-ID: References: <1477031080-12616-1-git-send-email-liang.z.li@intel.com> <580A4F81.60201@intel.com> <5810F1C7.4060807@intel.com> In-Reply-To: <5810F1C7.4060807@intel.com> 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" , "mst@redhat.com" Cc: "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "linux-mm@kvack.org" , "virtio-dev@lists.oasis-open.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "quintela@redhat.com" , "dgilbert@redhat.com" , "pbonzini@redhat.com" , "cornelia.huck@de.ibm.com" , "amit.shah@redhat.com" > On 10/26/2016 03:06 AM, Li, Liang Z wrote: > > I am working on Dave's new bitmap schema, I have finished the part of > > getting the 'hybrid scheme bitmap' and found the complexity was more > > than I expected. The main issue is more memory is required to save the > > 'hybrid scheme bitmap' beside that used to save the raw page bitmap, > > for the worst case, the memory required is 3 times than that in the > > previous implementation. >=20 > Really? Could you please describe the scenario where this occurs? > > I am wondering if I should continue, as an alternative solution, how > > about using PFNs array when inflating/deflating only a few pages? > > Things will be much more simple. >=20 > Yes, using pfn lists is more efficient than using bitmaps for sparse bitm= aps. > Yes, there will be cases where it is preferable to just use pfn lists vs.= any kind > of bitmap. >=20 > But, what does it matter? At least with your current scheme where we go > out and collect get_unused_pages(), we do the allocation up front. The > space efficiency doesn't matter at all for small sizes since we do the co= nstant- > size allocation *anyway*. >=20 > I'm also pretty sure you can pack the pfn and page order into a single 64= -bit > word and have no bitmap for a given record. That would make it pack just= as > well as the old pfns alone. Right? Yes, thanks for reminding, I am using 128 bit now, I will change it to 64 b= it. Let me finish the v4 first. Thanks! Liang =20 -- 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]:60397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzYuf-0007yk-Ku for qemu-devel@nongnu.org; Wed, 26 Oct 2016 20:51:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzYuc-0005uK-IC for qemu-devel@nongnu.org; Wed, 26 Oct 2016 20:51:21 -0400 Received: from mga07.intel.com ([134.134.136.100]:33386) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bzYuc-0005tR-AM for qemu-devel@nongnu.org; Wed, 26 Oct 2016 20:51:18 -0400 From: "Li, Liang Z" Date: Thu, 27 Oct 2016 00:51:13 +0000 Message-ID: References: <1477031080-12616-1-git-send-email-liang.z.li@intel.com> <580A4F81.60201@intel.com> <5810F1C7.4060807@intel.com> In-Reply-To: <5810F1C7.4060807@intel.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RESEND PATCH v3 kernel 0/7] 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" , "mst@redhat.com" Cc: "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "linux-mm@kvack.org" , "virtio-dev@lists.oasis-open.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "quintela@redhat.com" , "dgilbert@redhat.com" , "pbonzini@redhat.com" , "cornelia.huck@de.ibm.com" , "amit.shah@redhat.com" > On 10/26/2016 03:06 AM, Li, Liang Z wrote: > > I am working on Dave's new bitmap schema, I have finished the part of > > getting the 'hybrid scheme bitmap' and found the complexity was more > > than I expected. The main issue is more memory is required to save the > > 'hybrid scheme bitmap' beside that used to save the raw page bitmap, > > for the worst case, the memory required is 3 times than that in the > > previous implementation. >=20 > Really? Could you please describe the scenario where this occurs? > > I am wondering if I should continue, as an alternative solution, how > > about using PFNs array when inflating/deflating only a few pages? > > Things will be much more simple. >=20 > Yes, using pfn lists is more efficient than using bitmaps for sparse bitm= aps. > Yes, there will be cases where it is preferable to just use pfn lists vs.= any kind > of bitmap. >=20 > But, what does it matter? At least with your current scheme where we go > out and collect get_unused_pages(), we do the allocation up front. The > space efficiency doesn't matter at all for small sizes since we do the co= nstant- > size allocation *anyway*. >=20 > I'm also pretty sure you can pack the pfn and page order into a single 64= -bit > word and have no bitmap for a given record. That would make it pack just= as > well as the old pfns alone. Right? Yes, thanks for reminding, I am using 128 bit now, I will change it to 64 b= it. Let me finish the v4 first. Thanks! Liang =20