From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755202AbcLNI7x convert rfc822-to-8bit (ORCPT ); Wed, 14 Dec 2016 03:59:53 -0500 Received: from mga14.intel.com ([192.55.52.115]:39722 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755019AbcLNI7t (ORCPT ); Wed, 14 Dec 2016 03:59:49 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,346,1477983600"; d="scan'208";a="42344715" From: "Li, Liang Z" To: "Hansen, Dave" , Andrea Arcangeli CC: David Hildenbrand , "kvm@vger.kernel.org" , "mhocko@suse.com" , "mst@redhat.com" , "linux-kernel@vger.kernel.org" , "qemu-devel@nongnu.org" , "linux-mm@kvack.org" , "dgilbert@redhat.com" , "pbonzini@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "kirill.shutemov@linux.intel.com" Subject: RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Thread-Topic: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Thread-Index: AQHSSufi4SQjg1m8CEK5jUmkErPNiaD6HPWAgAJj94D//6QTgIAAAOqAgAAKNYCAAAnRgIAAHEuAgAAVUACAAAl0AIAClagg//+JqQCACJvLIA== Date: Wed, 14 Dec 2016 08:59:47 +0000 Message-ID: References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> <0b18c636-ee67-cbb4-1ba3-81a06150db76@redhat.com> <0b83db29-ebad-2a70-8d61-756d33e33a48@intel.com> <2171e091-46ee-decd-7348-772555d3a5e3@redhat.com> <20161207183817.GE28786@redhat.com> <20161207202824.GH28786@redhat.com> <060287c7-d1af-45d5-70ea-ad35d4bbeb84@intel.com> In-Reply-To: <060287c7-d1af-45d5-70ea-ad35d4bbeb84@intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjc2ZGMzOGUtMzk1Zi00MTY5LTliOTYtYjc5ZDQwYzAyYTU1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImtuMklneHJOdWdDemhIcUtDQVUrT2pqWVJVWjRLR1BlSGpIbEF2VEZHUUE9In0= 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: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding whether to ripping the bitmap from the ABI, > > am I right? > > I think Andrea and David feel pretty strongly that we should remove the > bitmap, unless we have some data to support keeping it. I don't feel as > strongly about it, but I think their critique of it is pretty valid. I think the > consensus is that the bitmap needs to go. > > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is pretty > strong. We don't need anywhere near 12 bits if doing power-of-2. Just found the MAX_ORDER should be limited to 12 if use length instead of order, If the MAX_ORDER is configured to a value bigger than 12, it will make things more complex to handle this case. If use order, we need to break a large memory range whose length is not the power of 2 into several small ranges, it also make the code complex. It seems we leave too many bit for the pfn, and the bits leave for length is not enough, How about keep 45 bits for the pfn and 19 bits for length, 45 bits for pfn can cover 57 bits physical address, that should be enough in the near feature. What's your opinion? thanks! Liang From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Li, Liang Z" Subject: RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Date: Wed, 14 Dec 2016 08:59:47 +0000 Message-ID: References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> <0b18c636-ee67-cbb4-1ba3-81a06150db76@redhat.com> <0b83db29-ebad-2a70-8d61-756d33e33a48@intel.com> <2171e091-46ee-decd-7348-772555d3a5e3@redhat.com> <20161207183817.GE28786@redhat.com> <20161207202824.GH28786@redhat.com> <060287c7-d1af-45d5-70ea-ad35d4bbeb84@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "mhocko@suse.com" , "kvm@vger.kernel.org" , "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" , Andrea Arcangeli Return-path: In-Reply-To: <060287c7-d1af-45d5-70ea-ad35d4bbeb84@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 > Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding whether to ripping the bitmap from the ABI, > > am I right? > > I think Andrea and David feel pretty strongly that we should remove the > bitmap, unless we have some data to support keeping it. I don't feel as > strongly about it, but I think their critique of it is pretty valid. I think the > consensus is that the bitmap needs to go. > > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is pretty > strong. We don't need anywhere near 12 bits if doing power-of-2. Just found the MAX_ORDER should be limited to 12 if use length instead of order, If the MAX_ORDER is configured to a value bigger than 12, it will make things more complex to handle this case. If use order, we need to break a large memory range whose length is not the power of 2 into several small ranges, it also make the code complex. It seems we leave too many bit for the pfn, and the bits leave for length is not enough, How about keep 45 bits for the pfn and 19 bits for length, 45 bits for pfn can cover 57 bits physical address, that should be enough in the near feature. What's your opinion? thanks! Liang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id 1E4626B0069 for ; Wed, 14 Dec 2016 03:59:52 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id g186so14924788pgc.2 for ; Wed, 14 Dec 2016 00:59:52 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com. [192.55.52.93]) by mx.google.com with ESMTPS id f1si51880039plm.190.2016.12.14.00.59.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Dec 2016 00:59:51 -0800 (PST) From: "Li, Liang Z" Subject: RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Date: Wed, 14 Dec 2016 08:59:47 +0000 Message-ID: References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> <0b18c636-ee67-cbb4-1ba3-81a06150db76@redhat.com> <0b83db29-ebad-2a70-8d61-756d33e33a48@intel.com> <2171e091-46ee-decd-7348-772555d3a5e3@redhat.com> <20161207183817.GE28786@redhat.com> <20161207202824.GH28786@redhat.com> <060287c7-d1af-45d5-70ea-ad35d4bbeb84@intel.com> In-Reply-To: <060287c7-d1af-45d5-70ea-ad35d4bbeb84@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" , Andrea Arcangeli Cc: David Hildenbrand , "kvm@vger.kernel.org" , "mhocko@suse.com" , "mst@redhat.com" , "linux-kernel@vger.kernel.org" , "qemu-devel@nongnu.org" , "linux-mm@kvack.org" , "dgilbert@redhat.com" , "pbonzini@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "kirill.shutemov@linux.intel.com" > Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration >=20 > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding whether to ripping the bitmap from the ABI, > > am I right? >=20 > I think Andrea and David feel pretty strongly that we should remove the > bitmap, unless we have some data to support keeping it. I don't feel as > strongly about it, but I think their critique of it is pretty valid. I t= hink the > consensus is that the bitmap needs to go. >=20 > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is p= retty > strong. We don't need anywhere near 12 bits if doing power-of-2. Just found the MAX_ORDER should be limited to 12 if use length instead of o= rder, If the MAX_ORDER is configured to a value bigger than 12, it will make thin= gs more complex to handle this case.=20 If use order, we need to break a large memory range whose length is not the= power of 2 into several small ranges, it also make the code complex. It seems we leave too many bit for the pfn, and the bits leave for length = is not enough, How about keep 45 bits for the pfn and 19 bits for length, 45 bits for pfn = can cover 57 bits physical address, that should be enough in the near feature.=20 What's your opinion? 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]:57990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cH5Pq-0004EI-9P for qemu-devel@nongnu.org; Wed, 14 Dec 2016 03:59:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cH5Pn-0003Qu-84 for qemu-devel@nongnu.org; Wed, 14 Dec 2016 03:59:58 -0500 Received: from mga06.intel.com ([134.134.136.31]:25319) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cH5Pm-0003Pq-UL for qemu-devel@nongnu.org; Wed, 14 Dec 2016 03:59:55 -0500 From: "Li, Liang Z" Date: Wed, 14 Dec 2016 08:59:47 +0000 Message-ID: References: <1480495397-23225-1-git-send-email-liang.z.li@intel.com> <0b18c636-ee67-cbb4-1ba3-81a06150db76@redhat.com> <0b83db29-ebad-2a70-8d61-756d33e33a48@intel.com> <2171e091-46ee-decd-7348-772555d3a5e3@redhat.com> <20161207183817.GE28786@redhat.com> <20161207202824.GH28786@redhat.com> <060287c7-d1af-45d5-70ea-ad35d4bbeb84@intel.com> In-Reply-To: <060287c7-d1af-45d5-70ea-ad35d4bbeb84@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] [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" , Andrea Arcangeli Cc: David Hildenbrand , "kvm@vger.kernel.org" , "mhocko@suse.com" , "mst@redhat.com" , "linux-kernel@vger.kernel.org" , "qemu-devel@nongnu.org" , "linux-mm@kvack.org" , "dgilbert@redhat.com" , "pbonzini@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "kirill.shutemov@linux.intel.com" > Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration >=20 > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding whether to ripping the bitmap from the ABI, > > am I right? >=20 > I think Andrea and David feel pretty strongly that we should remove the > bitmap, unless we have some data to support keeping it. I don't feel as > strongly about it, but I think their critique of it is pretty valid. I t= hink the > consensus is that the bitmap needs to go. >=20 > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is p= retty > strong. We don't need anywhere near 12 bits if doing power-of-2. Just found the MAX_ORDER should be limited to 12 if use length instead of o= rder, If the MAX_ORDER is configured to a value bigger than 12, it will make thin= gs more complex to handle this case.=20 If use order, we need to break a large memory range whose length is not the= power of 2 into several small ranges, it also make the code complex. It seems we leave too many bit for the pfn, and the bits leave for length = is not enough, How about keep 45 bits for the pfn and 19 bits for length, 45 bits for pfn = can cover 57 bits physical address, that should be enough in the near feature.=20 What's your opinion? thanks! Liang =20