From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v3] [linux-3.0+ for xen] tmem: self-ballooning and frontswap-selfshrinking Date: Thu, 30 Jun 2011 18:19:11 -0400 Message-ID: <20110630221911.GA18504@dumpdata.com> References: <426e12fd-fdba-4f83-9e9f-8832aaa5147e@default20110630215009.GA18218@dumpdata.com> <3726d065-0aba-4c98-bd56-5d4e952127dc@default> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <3726d065-0aba-4c98-bd56-5d4e952127dc@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: Daniel Kiper , jeremy@goop.org, xen-devel@lists.xensource.com, Ian Campbell , JBeulich@novell.com List-Id: xen-devel@lists.xenproject.org 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?