From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754464AbdDNOWw (ORCPT ); Fri, 14 Apr 2017 10:22:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40082 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752876AbdDNOWu (ORCPT ); Fri, 14 Apr 2017 10:22:50 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EB47980498 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mst@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com EB47980498 Date: Fri, 14 Apr 2017 17:22:43 +0300 From: "Michael S. Tsirkin" To: Matthew Wilcox Cc: Wei Wang , virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-mm@kvack.org, david@redhat.com, dave.hansen@intel.com, cornelia.huck@de.ibm.com, akpm@linux-foundation.org, mgorman@techsingularity.net, aarcange@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com, liliang.opensource@gmail.com Subject: Re: [PATCH v9 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Message-ID: <20170414171452-mutt-send-email-mst@kernel.org> References: <1492076108-117229-1-git-send-email-wei.w.wang@intel.com> <20170413204411.GJ784@bombadil.infradead.org> <20170414044515-mutt-send-email-mst@kernel.org> <20170414094740.GN784@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170414094740.GN784@bombadil.infradead.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 14 Apr 2017 14:22:50 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 14, 2017 at 02:47:40AM -0700, Matthew Wilcox wrote: > On Fri, Apr 14, 2017 at 04:50:48AM +0300, Michael S. Tsirkin wrote: > > On Thu, Apr 13, 2017 at 01:44:11PM -0700, Matthew Wilcox wrote: > > > On Thu, Apr 13, 2017 at 05:35:03PM +0800, Wei Wang wrote: > > > > 2) transfer the guest unused pages to the host so that they > > > > can be skipped to migrate in live migration. > > > > > > I don't understand this second bit. You leave the pages on the free list, > > > and tell the host they're free. What's preventing somebody else from > > > allocating them and using them for something? Is the guest semi-frozen > > > at this point with just enough of it running to ask the balloon driver > > > to do things? > > > > There's missing documentation here. > > > > The way things actually work is host sends to guest > > a request for unused pages and then write-protects all memory. > > ... hopefully you mean "write protects all memory, then sends a request > for unused pages", otherwise there's a race condition. Exactly. > And I see the utility of this, but does this functionality belong in > the balloon driver? We have historically put all kind of memory-related functionality in the balloon device. Consider for example memory statistics - seems related conceptually. See patches 1-2: the new mechanism for reporting lists of pages seems to be benefitial for both which seems to indicate using the balloon for this is a good idea. > It seems like it's something you might want even if you don't have the > balloon driver loaded. Or something you might not want if you do have > the balloon driver loaded. Most of balloon functionality is kind of loosely coupled. Yes we could split it up but I'm not sure what would this buy us. What do you have in mind? -- MST