VMware Balloon driver
in [Kernel]
|
From: Dmitry Torokhov on 5 Apr 2010 19:30 On Mon, Apr 05, 2010 at 04:11:10PM -0700, Andrew Morton wrote: > On Mon, 5 Apr 2010 16:03:48 -0700 (PDT) > Dan Magenheimer <dan.magenheimer(a)oracle.com> wrote: > > > > > On 04/06/2010 01:17 AM, Andrew Morton wrote: > > > > >> The basic idea of the driver is to allow a guest system to give up > > > > >> memory it isn't using so it can be reused by other virtual > > > machines (or > > > > >> the host itself). > > > > >> > > > > > So... does this differ in any fundamental way from what > > > hibernation > > > > > does, via shrink_all_memory()? > > > > > > > > > > > > > Just the _all_ bit, and the fact that we need to report the freed > > > page > > > > numbers to the hypervisor. > > > > > > > > > > So... why not tweak that, rather than implementing some parallel > > > thing? > > > > I think Avi was being facetious ("_all_"). Hibernation assumes > > everything in the machine is going to stop for awhile. Ballooning > > assumes that the machine has lower memory need for awhile, but > > is otherwise fully operational. > > shrink_all_memory() doesn't require that processes be stopped. > > If the existing code doesn't exactly match virtualisation's > requirements, it can be changed. > > > Think of it as hot-plug memory > > at a page granularity. > > hotplug is different because it targets particular physical pages. For > this requirement any old page will do. Preferably one which won't be > needed soon, yes? The best page would not old page but unused page. We do rely on the standard mechanisms to find pages that can be freed to inflate balloon, but once pages are allocated they are not available till released. In case of shrinkig memory it can be allocated and used as soon as we wake up (it shrink was done in course of hibernation sequence). -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 5 Apr 2010 19:40 On Mon, 05 Apr 2010 16:28:38 -0700 Jeremy Fitzhardinge <jeremy(a)goop.org> wrote: > And is there some way to get the vm subsystem to provide backpressure: > "I'm getting desperately short of memory!"? Not really. One could presumably pull dopey tricks by hooking into slab shrinker registration or even ->writepage(). But cooking up something explicit doesn't sound too hard - the trickiest bit would be actually defining what it should do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dan Magenheimer on 5 Apr 2010 20:30 > From: Andrew Morton [mailto:akpm(a)linux-foundation.org] > Sent: Monday, April 05, 2010 5:35 PM > To: Jeremy Fitzhardinge > Cc: Dmitry Torokhov; linux-kernel(a)vger.kernel.org; pv- > drivers(a)vmware.com; Avi Kivity; Dan Magenheimer > Subject: Re: [PATCH] VMware Balloon driver > > On Mon, 05 Apr 2010 16:28:38 -0700 > Jeremy Fitzhardinge <jeremy(a)goop.org> wrote: > > > And is there some way to get the vm subsystem to provide > backpressure: > > "I'm getting desperately short of memory!"? > > Not really. One could presumably pull dopey tricks by hooking into > slab shrinker registration or even ->writepage(). But cooking up > something explicit doesn't sound too hard - the trickiest bit would be > actually defining what it should do. Sorry, I don't mean to be too self-serving. And I am far less an expert in Linux mm code than others involved in this discussion. But this backpressure metric is one thing that frontswap provides. It also provides an "insurance policy" for "desperately short of memory". It is the "yin" to the "yang" of cleancache. If I understand the swap subsystem correctly, there IS NO "getting desperately short of memory" except when a swap device is unavailable or, more likely, too darn slow. Frontswap writes synchronously to pseudo-RAM (tmem, in the case of Xen) instead of a slow asynchronous swap device. It hooks directly into swap_writepage()/swap_readpage() in a very clean, well-defined (not dopey) way. So -- I think -- it is a perfect feedback mechanism to tell a balloon driver (or equivalent), "I need more memory" while covering the short-term need until the balloon driver (and/or hypervisor) can respond. It works today with Xen, and Nitin Gupta is working on an in-kernel memory compression backend for it. And Chris Mason and I think it may also be a fine interface for SSD-used- as-RAM-extension. So please consider frontswap and cleancache before "cooking up something [else] explicit"... these were previously part of Transcendent Memory postings*, but I have revised them to be more useful, well-defined, and standalone (from Xen/tmem) and will be re-posting the revised versions soon. Dan * See: http://lwn.net/Articles/340080/ http://lkml.indiana.edu/hypermail/linux/kernel/0912.2/01322.html OLS 2009 proceedings LCA 2010 proceedings -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 6 Apr 2010 12:30 On 04/06/2010 01:40 AM, Andrew Morton wrote: > On Tue, 06 Apr 2010 01:26:11 +0300 > Avi Kivity<avi(a)redhat.com> wrote: > > >> On 04/06/2010 01:17 AM, Andrew Morton wrote: >> >>>> The basic idea of the driver is to allow a guest system to give up >>>> memory it isn't using so it can be reused by other virtual machines (or >>>> the host itself). >>>> >>>> >>> So... does this differ in any fundamental way from what hibernation >>> does, via shrink_all_memory()? >>> >>> >> Just the _all_ bit, and the fact that we need to report the freed page >> numbers to the hypervisor. >> >> > So... why not tweak that, rather than implementing some parallel thing? > That's maybe 5 lines of code. Most of the code is focused on interpreting requests from the hypervisor and replying with the page numbers. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 6 Apr 2010 13:00
On 04/06/2010 01:58 AM, Dmitry Torokhov wrote: > >> Also please explain the applicability of this driver. Will xen use it? >> kvm? Out-of-tree code? >> > The driver is expected to be used on VMware platform - mainly ESX. > Originally we tried to converge with KVM and use virtio and > stock virtio_balloon driver but Avi mentioned that our code emulating > virtqueue was more than balloon code itself and thus using virtio did > not make nuch sense. > Yeah. If we wanted commonality, we could make a balloon_core.c that contains the common code. IMO that's premature, but perhaps there's some meat there (like suspend/resume support and /proc//sys interface). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |