[lkml]   [2009]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed)
    On Sun, 2009-08-16 at 08:34 -0700, Arjan van de Ven wrote:
    > On Sun, 16 Aug 2009 15:05:30 +0100
    > Alan Cox <> wrote:
    > > On Sat, 15 Aug 2009 08:55:17 -0500
    > > James Bottomley <> wrote:
    > >
    > > > On Sat, 2009-08-15 at 09:22 -0400, Mark Lord wrote:
    > > > > James Bottomley wrote:
    > > > > >
    > > > > > This means you have to drain the outstanding NCQ commands
    > > > > > (stalling the device) before you can send a TRIM. If we do
    > > > > > this for every discard, the performance impact will be pretty
    > > > > > devastating, hence the need to coalesce. It's nothing really
    > > > > > to do with device characteristics, it's an ATA protocol problem.
    > > > > ..
    > > > >
    > > > > I don't think that's really much of an issue -- we already have
    > > > > to do that for cache-flushes whenever barriers are enabled. Yes
    > > > > it costs, but not too much.
    > > >
    > > > That's not really what the enterprise is saying about flush
    > > > barriers. True, not all the performance problems are NCQ queue
    > > > drain, but for a steady workload they are significant.
    > >
    > > Flush barriers are nightmare for more than enterprise. You drive
    > > basically goes for a hike for a bit which trashes interactivity as
    > > well. If the device can't do trim and the like without a drain I
    > > don't see much point doing it at all, except maybe to wait for idle
    > > devices and run a filesystem managed background 'strimmer' thread to
    > > just weed out now idle blocks that have stayed idle - eg by adding an
    > > inode of all the deleted untrimmed blocks and giving it an irregular
    > > empty ?
    > trim is mostly for ssd's though, and those tend to not have the "goes
    > for a hike" behavior as much......

    Well, yes and no ... a lot of SSDs don't actually implement NCQ, so the
    impact to them will be less ... although I think enterprise class SSDs
    do implement NCQ.

    > I wonder if it's worse to batch stuff up, because then the trim itself
    > gets bigger and might take longer.....

    So this is where we're getting into the realms of speculation. There
    really are only about a couple of people out there with trim
    implementing SSDs, so that's not really enough to make any judgement.

    However, the enterprise has been doing UNMAP for a while, so we can draw
    inferences from them since the SSD FTL will operate similarly. For
    them, UNMAP is the same cost in terms of time regardless of the number
    of extents. The reason is that it's moving the blocks from the global
    in use list to the global free list. Part of the problem is that this
    involves locking and quiescing, so UNMAP ends up being quite expensive
    to the array but constant in terms of cost (hence they want as few
    unmaps for as many sectors as possible).

    For SSDs, the FTL has to have a separate operation: erase. Now, one
    could see the correct implementation simply moving the sectors from the
    in-use list to the to be cleaned list and still do the cleaning in the
    background: that would be constant cost (but, again, likely expensive).
    Of course, if SSD vendors decided to erase on the spot when seeing TRIM,
    this wouldn't be true ...


     \ /
      Last update: 2009-08-16 17:55    [W:0.024 / U:305.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site