From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761990AbcLPQBa (ORCPT ); Fri, 16 Dec 2016 11:01:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57120 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755455AbcLPQBU (ORCPT ); Fri, 16 Dec 2016 11:01:20 -0500 Date: Fri, 16 Dec 2016 17:01:12 +0100 From: Andrea Arcangeli To: Dave Hansen Cc: "Li, Liang Z" , 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 Message-ID: <20161216160112.GC6168@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84ac9822-880d-b998-52ca-6aa87e0f7a43@intel.com> User-Agent: Mutt/1.7.2 (2016-11-26) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 16 Dec 2016 16:01:15 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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? Thanks, Andrea