RE: [PATCH] VMware Balloon driver

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Andrew Morton [mailto:akpm@linux-foundation.org]
> Sent: Monday, April 05, 2010 5:35 PM
> To: Jeremy Fitzhardinge
> Cc: Dmitry Torokhov; linux-kernel@vger.kernel.org; pv-
> drivers@vmware.com; Avi Kivity; Dan Magenheimer
> Subject: Re: [PATCH] VMware Balloon driver
> 
> On Mon, 05 Apr 2010 16:28:38 -0700
> Jeremy Fitzhardinge <jeremy@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