lkml.org 
[lkml]   [2010]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Frontswap [PATCH 0/4] (was Transcendent Memory): overview
From
Date
On Wed, 2010-04-28 at 07:55 +0200, Pavel Machek wrote:
> > > Seems frontswap is like a reverse balloon, where the balloon is in
> > > hypervisor space instead of the guest space.
> >
> > That's a reasonable analogy. Frontswap serves nicely as an
> > emergency safety valve when a guest has given up (too) much of
> > its memory via ballooning but unexpectedly has an urgent need
> > that can't be serviced quickly enough by the balloon driver.
>
> wtf? So lets fix the ballooning driver instead?
>
> There's no reason it could not be as fast as frontswap, right?
> Actually I'd expect it to be faster -- it can deal with big chunks.

Frontswap and things like CMM2[1] have some fundamental advantages over
swapping and ballooning. First of all, there are serious limits on
ballooning. It's difficult for a guest to span a very wide range of
memory sizes without also including memory hotplug in the mix. The ~1%
'struct page' penalty alone causes issues here.

A large portion of CMM2's gain came from the fact that you could take
memory away from guests without _them_ doing any work. If the system is
experiencing a load spike, you increase load even more by making the
guests swap. If you can just take some of their memory away, you can
smooth that spike out. CMM2 and frontswap do that. The guests
explicitly give up page contents that the hypervisor does not have to
first consult with the guest before discarding.

[1] http://www.kernel.org/doc/ols/2006/ols2006v2-pages-321-336.pdf

-- Dave



\
 
 \ /
  Last update: 2010-04-30 19:21    [W:0.142 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site