lkml.org 
[lkml]   [2010]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Frontswap [PATCH 0/4] (was Transcendent Memory): overview
    Hi!

    > > > Nevertheless, frontswap works great today with a bare-metal
    > > > hypervisor. I think it stands on its own merits, regardless
    > > > of one's vision of future SSD/memory technologies.
    > >
    > > Even when frontswapping to RAM on a bare metal hypervisor it makes
    > > sense
    > > to use an async API, in case you have a DMA engine on board.
    >
    > When pages are 2MB, this may be true. When pages are 4KB and
    > copied individually, it may take longer to program a DMA engine
    > than to just copy 4KB.
    >
    > But in any case, frontswap works fine on all existing machines
    > today. If/when most commodity CPUs have an asynchronous RAM DMA
    > engine, an asynchronous API may be appropriate. Or the existing
    > swap API might be appropriate. Or the synchronous frontswap API
    > may work fine too. Speculating further about non-existent
    > hardware that might exist in the (possibly far) future is irrelevant
    > to the proposed patch, which works today on all existing x86 hardware
    > and on shipping software.

    If we added all the apis that worked when proposed, we'd have
    unmaintanable mess by about 1996.

    Why can't frontswap just use existing swap api?
    Pavel

    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


    \
     
     \ /
      Last update: 2010-04-27 14:59    [W:0.021 / U:66.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site