lkml.org 
[lkml]   [2009]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Tmem [PATCH 0/5] (Take 3): Transcendent memory
Hi!

> > 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 :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


\
 
 \ /
  Last update: 2009-12-28 21:53    [W:0.072 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site