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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Pavel Machek [mailto:pavel@xxxxxx]
> > > As I mentioned, I really like the idea behind tmem. All I 
> am proposing
> > > is that we should probably explore some alternatives to 
> 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.

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
is configured, this difference probably doesn't make much
difference though.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel