From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH] Add a page cache-backed balloon device driver. Date: Wed, 27 Jun 2012 19:06:44 +0300 Message-ID: <20120627160644.GD21393@redhat.com> References: <1340742778-11282-1-git-send-email-fes@google.com> <20120626214106.GC14054@redhat.com> <87lij91myw.fsf@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: 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 To: Frank Swiderski Cc: Andrea Arcangeli , riel@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, mikew@google.com List-Id: virtualization@lists.linuxfoundation.org On Wed, Jun 27, 2012 at 08:48:55AM -0700, Frank Swiderski wrote: > On Tue, Jun 26, 2012 at 7:56 PM, Rusty Russell wr= ote: > > On Wed, 27 Jun 2012 00:41:06 +0300, "Michael S. Tsirkin" wrote: > >> On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote: > >> > This implementation of a virtio balloon driver uses the page cache to > >> > "store" pages that have been released to the host. =A0The communicat= ion > >> > (outside of target counts) is one way--the guest notifies the host w= hen > >> > it adds a page to the page cache, allowing the host to madvise(2) wi= th > >> > MADV_DONTNEED. =A0Reclaim in the guest is therefore automatic and im= plicit > >> > (via the regular page reclaim). =A0This means that inflating the bal= loon > >> > is similar to the existing balloon mechanism, but the deflate is > >> > different--it re-uses existing Linux kernel functionality to > >> > automatically reclaim. > >> > > >> > Signed-off-by: Frank Swiderski > >> > >> I'm pondering this: > >> > >> Should it really be a separate driver/device ID? > >> If it behaves the same from host POV, maybe it > >> should be up to the guest how to inflate/deflate > >> the balloon internally? > > > > Well, it shouldn't steal ID 10, either way :) =A0Either use a completely > > bogus number, or ask for an id. > > > > But AFAICT this should be a an alternate driver of for the same device: > > it's not really a separate device, is it? > > > > Cheers, > > Rusty. > = > Apologies, Rusty. Asking for an ID is in the virtio spec, and I > completely neglected that step. Though as you and others have pointed > out, this probably fits better as a different driver for the same > device. Since it changes whether or not the deflate operation is > necessary, it also seems that how this should look is different > behavior based on a feature bit in the device. > = > If that sounds reasonable, then what I'll do with this patch is merge > it with the existing virtio balloon driver with a feature bit for > determining which behavior to use. > = > I also think the idea of a generic balloon that the different balloon > drivers use for the inflate/deflate operations is interesting and > useful, though I think the suggestion of pending that until later is > correct. > = > Sounds reasonable? > = > Regards, > fes I think a spec patch would be a good spec at this point. You can get the spec from Rusty, or a mirror from my git: git://git.kernel.org/pub/scm/virt/kvm/mst/virtio-spec.git