From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754500AbcLQMjH convert rfc822-to-8bit (ORCPT ); Sat, 17 Dec 2016 07:39:07 -0500 Received: from mga07.intel.com ([134.134.136.100]:35280 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751711AbcLQMjG (ORCPT ); Sat, 17 Dec 2016 07:39:06 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,363,1477983600"; d="scan'208";a="1100565528" From: "Li, Liang Z" To: Andrea Arcangeli , "Hansen, Dave" 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//+JqQCACJvLIIABhXGAgAEgGHD//4B0AAARFHcg//+AL4CAAPBoAP/+LL5w Date: Sat, 17 Dec 2016 12:39:01 +0000 Message-ID: References: <20161207202824.GH28786@redhat.com> <060287c7-d1af-45d5-70ea-ad35d4bbeb84@intel.com> <01886693-c73e-3696-860b-086417d695e1@intel.com> <84ac9822-880d-b998-52ca-6aa87e0f7a43@intel.com> <20161216160112.GC6168@redhat.com> In-Reply-To: <20161216160112.GC6168@redhat.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDA2YzI3OTgtNGU5Yy00NmFlLTkxYTktZTJiZWUwYTFiMGQzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Im1iaUYrcXhTVWpkNlVidytpbUNoMzFcL1NpUVAwdHVhK3ZvT1Jka2pqb2o4PSJ9 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 Thu, Dec 15, 2016 at 05:40:45PM -0800, Dave Hansen wrote: > > On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > > > Use 52 bits for 'pfn', 12 bits for 'length', when the 12 bits is not long > enough for the 'length' > > > Set the 'length' to a special value to indicate the "actual length in next 8 > bytes". > > > > > > That will be much more simple. Right? > > > > Sounds fine to me. > > > > Sounds fine to me too indeed. > > I'm only wondering what is the major point for compressing gpfn+len in > 8 bytes in the common case, you already use sg_init_table to send down two > pages, we could send three as well and avoid all math and bit shifts and ors, > or not? > Yes, we can use more pages for that. > I agree with the above because from a performance prospective I tend to > think the above proposal will run at least theoretically faster because the > other way is to waste double amount of CPU cache, and bit mangling in the > encoding and the later decoding on qemu side should be faster than > accessing an array of double size, but then I'm not sure if it's measurable > optimization. So I'd be curious to know the exact motivation and if it is to > reduce the CPU cache usage or if there's some other fundamental reason to > compress it. > The header already tells qemu how big is the array payload, couldn't we just > add more pages if one isn't enough? > The original intention to compress the PFN and length it's to reduce the memory required. Even the code was changed a lot from the previous versions, I think this is still true. Now we allocate a specified buffer size to save the 'PFN|length', when the buffer is not big enough to save all the page info for a specified order. A double size buffer will be allocated. This is what we want to avoid because the allocation may fail and allocation takes some time, for fast live migration, time is a critical factor we have to consider, more time takes means more unnecessary pages are sent, because live migration starts before the request for unused pages get response. Thanks Liang > Thanks, > Andrea 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: Sat, 17 Dec 2016 12:39:01 +0000 Message-ID: References: <20161207202824.GH28786@redhat.com> <060287c7-d1af-45d5-70ea-ad35d4bbeb84@intel.com> <01886693-c73e-3696-860b-086417d695e1@intel.com> <84ac9822-880d-b998-52ca-6aa87e0f7a43@intel.com> <20161216160112.GC6168@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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" To: Andrea Arcangeli , "Hansen, Dave" Return-path: In-Reply-To: <20161216160112.GC6168@redhat.com> Content-Language: en-US Sender: owner-linux-mm@kvack.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 >=20 > On Thu, Dec 15, 2016 at 05:40:45PM -0800, Dave Hansen wrote: > > On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > > > Use 52 bits for 'pfn', 12 bits for 'length', when the 12 bits is not = long > enough for the 'length' > > > Set the 'length' to a special value to indicate the "actual length in= next 8 > bytes". > > > > > > That will be much more simple. Right? > > > > Sounds fine to me. > > >=20 > Sounds fine to me too indeed. >=20 > I'm only wondering what is the major point for compressing gpfn+len in > 8 bytes in the common case, you already use sg_init_table to send down tw= o > pages, we could send three as well and avoid all math and bit shifts and = ors, > or not? >=20 Yes, we can use more pages for that. > I agree with the above because from a performance prospective I tend to > think the above proposal will run at least theoretically faster because t= he > other way is to waste double amount of CPU cache, and bit mangling in the > encoding and the later decoding on qemu side should be faster than > accessing an array of double size, but then I'm not sure if it's measurab= le > optimization. So I'd be curious to know the exact motivation and if it is= to > reduce the CPU cache usage or if there's some other fundamental reason to > compress it. > The header already tells qemu how big is the array payload, couldn't we j= ust > add more pages if one isn't enough? >=20 The original intention to compress the PFN and length it's to reduce the me= mory required. Even the code was changed a lot from the previous versions, I think this is= still true. Now we allocate a specified buffer size to save the 'PFN|length', when the = buffer is not big enough to save all the page info for a specified order. A double size buffe= r will be allocated. This is what we want to avoid because the allocation may fail and allocatio= n takes some time, for fast live migration, time is a critical factor we have to consider, mor= e time takes means more unnecessary pages are sent, because live migration starts before the r= equest for unused pages get response.=20 Thanks Liang > Thanks, > Andrea -- 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]:44463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIEGd-0007ih-FJ for qemu-devel@nongnu.org; Sat, 17 Dec 2016 07:39:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIEGa-0006lL-CW for qemu-devel@nongnu.org; Sat, 17 Dec 2016 07:39:11 -0500 Received: from mga14.intel.com ([192.55.52.115]:1869) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cIEGa-0006hp-0c for qemu-devel@nongnu.org; Sat, 17 Dec 2016 07:39:08 -0500 From: "Li, Liang Z" Date: Sat, 17 Dec 2016 12:39:01 +0000 Message-ID: References: <20161207202824.GH28786@redhat.com> <060287c7-d1af-45d5-70ea-ad35d4bbeb84@intel.com> <01886693-c73e-3696-860b-086417d695e1@intel.com> <84ac9822-880d-b998-52ca-6aa87e0f7a43@intel.com> <20161216160112.GC6168@redhat.com> In-Reply-To: <20161216160112.GC6168@redhat.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: Andrea Arcangeli , "Hansen, Dave" 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 Thu, Dec 15, 2016 at 05:40:45PM -0800, Dave Hansen wrote: > > On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > > > Use 52 bits for 'pfn', 12 bits for 'length', when the 12 bits is not = long > enough for the 'length' > > > Set the 'length' to a special value to indicate the "actual length in= next 8 > bytes". > > > > > > That will be much more simple. Right? > > > > Sounds fine to me. > > >=20 > Sounds fine to me too indeed. >=20 > I'm only wondering what is the major point for compressing gpfn+len in > 8 bytes in the common case, you already use sg_init_table to send down tw= o > pages, we could send three as well and avoid all math and bit shifts and = ors, > or not? >=20 Yes, we can use more pages for that. > I agree with the above because from a performance prospective I tend to > think the above proposal will run at least theoretically faster because t= he > other way is to waste double amount of CPU cache, and bit mangling in the > encoding and the later decoding on qemu side should be faster than > accessing an array of double size, but then I'm not sure if it's measurab= le > optimization. So I'd be curious to know the exact motivation and if it is= to > reduce the CPU cache usage or if there's some other fundamental reason to > compress it. > The header already tells qemu how big is the array payload, couldn't we j= ust > add more pages if one isn't enough? >=20 The original intention to compress the PFN and length it's to reduce the me= mory required. Even the code was changed a lot from the previous versions, I think this is= still true. Now we allocate a specified buffer size to save the 'PFN|length', when the = buffer is not big enough to save all the page info for a specified order. A double size buffe= r will be allocated. This is what we want to avoid because the allocation may fail and allocatio= n takes some time, for fast live migration, time is a critical factor we have to consider, mor= e time takes means more unnecessary pages are sent, because live migration starts before the r= equest for unused pages get response.=20 Thanks Liang > Thanks, > Andrea