[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
    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.


    -- Dave

     \ /
      Last update: 2010-04-30 19:21    [W:0.021 / U:2.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site