From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934417AbcJZSLY (ORCPT ); Wed, 26 Oct 2016 14:11:24 -0400 Received: from mga07.intel.com ([134.134.136.100]:14435 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933846AbcJZSLU (ORCPT ); Wed, 26 Oct 2016 14:11:20 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,551,1473145200"; d="scan'208";a="24365216" Subject: Re: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration To: "Li, Liang Z" , "mst@redhat.com" References: <1477031080-12616-1-git-send-email-liang.z.li@intel.com> <580A4F81.60201@intel.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" From: Dave Hansen Message-ID: <5810F1C7.4060807@intel.com> Date: Wed, 26 Oct 2016 11:11:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration Date: Wed, 26 Oct 2016 11:11:19 -0700 Message-ID: <5810F1C7.4060807@intel.com> References: <1477031080-12616-1-git-send-email-liang.z.li@intel.com> <580A4F81.60201@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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" To: "Li, Liang Z" , "mst@redhat.com" Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.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? -- 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]:43916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzSfi-0003NB-Ql for qemu-devel@nongnu.org; Wed, 26 Oct 2016 14:11:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzSfd-0000pt-3D for qemu-devel@nongnu.org; Wed, 26 Oct 2016 14:11:30 -0400 Received: from mga04.intel.com ([192.55.52.120]:13635) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bzSfc-0000nn-QX for qemu-devel@nongnu.org; Wed, 26 Oct 2016 14:11:25 -0400 References: <1477031080-12616-1-git-send-email-liang.z.li@intel.com> <580A4F81.60201@intel.com> From: Dave Hansen Message-ID: <5810F1C7.4060807@intel.com> Date: Wed, 26 Oct 2016 11:11:19 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: "Li, Liang Z" , "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. 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?