lkml.org 
[lkml]   [2011]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] mm: frontswap (for 3.2 window)
On 11/02/2011 06:02 PM, Andrea Arcangeli wrote:
> Hi Avi,
>
> On Wed, Nov 02, 2011 at 05:44:50PM +0200, Avi Kivity wrote:
> > If you look at cleancache, then it addresses this concern - it extends
> > pagecache through host memory. When dropping a page from the tail of
> > the LRU it first goes into tmem, and when reading in a page from disk
> > you first try to read it from tmem. However in many workloads,
> > cleancache is actually detrimental. If you have a lot of cache misses,
> > then every one of them causes a pointless vmexit; considering that
> > servers today can chew hundreds of megabytes per second, this adds up.
> > On the other side, if you have a use-once workload, then every page that
> > falls of the tail of the LRU causes a vmexit and a pointless page copy.
>
> I also think it's bad design for Virt usage, but hey, without this
> they can't even run with cache=writeback/writethrough and they're
> forced to cache=off, and then they claim specvirt is marketing, so for
> Xen it's better than nothing I guess.

Surely Xen can use the pagecache, it uses Linux for I/O just like kvm.

> I'm trying right now to evaluate it as a pure zcache host side
> optimization.

zcache style usage is fine. It's purely internal so no ABI constraints,
and no hypercalls either. It's still synchronous though so RAMster like
approaches will not work well.


<snip>

--
error compiling committee.c: too many arguments to function



\
 
 \ /
  Last update: 2011-11-02 17:15    [W:0.103 / U:15.112 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site