This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: Tmem [PATCH 0/5] (Take 3): Transcendent memory

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: [Xen-devel] Re: Tmem [PATCH 0/5] (Take 3): Transcendent memory
From: Pavel Machek <pavel@xxxxxx>
Date: Mon, 28 Dec 2009 21:51:03 +0100
Cc: Nick Piggin <npiggin@xxxxxxx>, sunil.mushran@xxxxxxxxxx, jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, tmem-devel@xxxxxxxxxxxxxx, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>, linux-mm <linux-mm@xxxxxxxxx>, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, dave.mccracken@xxxxxxxxxx, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, chris.mason@xxxxxxxxxx, Avi Kivity <avi@xxxxxxxxxx>, Schwidefsky <schwidefsky@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Nitin Gupta <ngupta@xxxxxxxxxx>, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 28 Dec 2009 12:51:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <f4ab13eb-daaa-40be-82ad-691505b1f169@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20091225191848.GB8438@xxxxxxxxxx> <f4ab13eb-daaa-40be-82ad-691505b1f169@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)

> > achive this using
> > > > some existing infrastructure in kernel.
> > > 
> > > Hi Nitin --
> > > 
> > > Sorry if I sounded overly negative... too busy around the holidays.
> > > 
> > > I'm definitely OK with exploring alternatives.  I just think that
> > > existing kernel mechanisms are very firmly rooted in the notion
> > > that either the kernel owns the memory/cache or an asynchronous
> > > device owns it.  Tmem falls somewhere in between and is very
> > 
> > Well... compcache seems to be very similar to preswap: in preswap case
> > you don't know if hypervisor will have space, in ramzswap you don't
> > know if data are compressible.
> Hi Pavel --
> Yes there are definitely similarities too.  In fact, I started
> prototyping preswap (now called frontswap) with Nitin's
> compcache code.  IIRC I ran into some problems with compcache's
> difficulties in dealing with failed "puts" due to dynamic
> changes in size of hypervisor-available-memory.
> Nitin may have addressed this in later versions of ramzswap.

That would be cool to find out.

> One feature of frontswap which is different than ramzswap is
> that frontswap acts as a "fronting store" for all configured
> swap devices, including SAN/NAS swap devices.  It doesn't
> need to be separately configured as a "highest priority" swap
> device.  In many installations and depending on how ramzswap

Ok, I'd call it a bug, not a feature :-).
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>