Re: [PATCH v3] [linux-3.0+ for xen] tmem: self-ballooning and frontswap-selfshrinking

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Jun 30, 2011 at 03:08:41PM -0700, Dan Magenheimer wrote:
> > From: Konrad Rzeszutek Wilk
> > Sent: Thursday, June 30, 2011 3:50 PM
> > To: Dan Magenheimer
> > Cc: xen-devel@lists.xensource.com; JBeulich@novell.com; jeremy@goop.org; Ian Campbell; Daniel Kiper
> > Subject: Re: [PATCH v3] [linux-3.0+ for xen] tmem: self-ballooning and frontswap-selfshrinking
> > 
> > > ("tmem") functionality that complement cleancache and frontswap.  Both
> > > use control theory to dynamically adjust and optimize memory utilization.
> > > Selfballooning controls the in-kernel Xen balloon driver, targeting a goal
> > > value (vm_committed_as), thus pushing less frequently used clean
> > > page cache pages (through the cleancache code) into Xen tmem where
> > > Xen can balance needs across all VMs residing on the physical machine.
> > 
> > Can this be used by KVM or HyperV code? Can it be made generic? If so, why not?
> > If only Xen can use this, what would it entail for other balloon drivers
> > to use this? Or is it that they really don't need to b/c none of them
> > use the clean cache code?
> 
> I'm not an expert on KVM nor on HyperV.  If either becomes capable
> of supporting tmem and if the KVM/HyperV equivalent of balloon drivers
> are suitable, concepts similar to selfballooning and frontswap-selfshrinking
> are likely useful, though it would require quite a bit more study to
> try to guess at how one might make the proposed code generic.
> 
> I expect to talk to folk at the upcoming KVM Forum to consider
> next steps, and another proposed patch (https://lkml.org/lkml/2011/6/30/354)
> moves the in-kernel tmem support one step closer to supporting KVM.
> 
> It's been awhile since I've communicated with Ky about tmem so I will
> re-open that conversation.
> 
> But it will probably be months/years before generic'izing this proposed
> patch is feasible.  Seems best to cross that bridge later.

The mechanism this patch employs to "balloon" is quite generic - it uses the
shrinker API. I am trying to understand from a technical perspective why this
code cannot be outside Xen as generic code?