Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753514AbcLGQWB (ORCPT ); Wed, 7 Dec 2016 11:22:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41522 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752395AbcLGQV7 (ORCPT ); Wed, 7 Dec 2016 11:21:59 -0500 Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration To: Dave Hansen , "Li, Liang Z" , "kvm@vger.kernel.org" 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> Cc: "virtio-dev@lists.oasis-open.org" , "mhocko@suse.com" , "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" , Andrea Arcangeli From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <2171e091-46ee-decd-7348-772555d3a5e3@redhat.com> Date: Wed, 7 Dec 2016 17:21:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0b83db29-ebad-2a70-8d61-756d33e33a48@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 07 Dec 2016 16:21:58 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1421 Lines: 40 >>> >>> I did something similar. Filled the balloon with 15GB for a 16GB idle >>> guest, by >>> using bitmap, the madvise count was reduced to 605. when using the >>> PFNs, the madvise count >>> was 3932160. It means there are quite a lot consecutive bits in the >>> bitmap. >>> I didn't test for a guest with heavy memory workload. >> >> Would it then even make sense to go one step further and report {pfn, >> length} combinations? >> >> So simply send over an array of {pfn, length}? > > Li's current patches do that. Well, maybe not pfn/length, but they do > take a pfn and page-order, which fits perfectly with the kernel's > concept of high-order pages. So we can send length in powers of two. Still, I don't see any benefit over a simple pfn/len schema. But I'll have a more detailed look at the implementation first, maybe that will enlighten me :) > >> And it makes sense if you think about: >> >> a) hugetlb backing: The host may only be able to free huge pages (we >> might want to communicate that to the guest later, that's another >> story). Still we would have to send bitmaps full of 4k frames (512 bits >> for 2mb frames). Of course, we could add a way to communicate that we >> are using a different bitmap-granularity. > > Yeah, please read the patches. If they're not clear, then the > descriptions need work, but this is done already. > I missed the page_shift, thanks for the hint. -- David