[lkml]   [2011]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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.


error compiling committee.c: too many arguments to function

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