|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] RE: Tmem [PATCH 0/5] (Take 3): Transcendent memory
To: |
Pavel Machek <pavel@xxxxxx> |
Subject: |
[Xen-devel] RE: Tmem [PATCH 0/5] (Take 3): Transcendent memory |
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
Date: |
Mon, 28 Dec 2009 07:57:28 -0800 (PST) |
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>, Andrew, dave.mccracken@xxxxxxxxxx, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, chris.mason@xxxxxxxxxx, Avi Kivity <avi@xxxxxxxxxx>, Schwidefsky <schwidefsky@xxxxxxxxxx>, Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Nitin Gupta <ngupta@xxxxxxxxxx>, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> |
Delivery-date: |
Mon, 04 Jan 2010 04:53:58 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<20091225191848.GB8438@xxxxxxxxxx> |
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> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
> 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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] RE: Tmem [PATCH 0/5] (Take 3): Transcendent memory,
Dan Magenheimer <=
|
|
|
|
|