[lkml]   [2009]   [Aug]   [13]   [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 08/13/2009 11:43 AM, James Bottomley wrote:
    > On Thu, 2009-08-13 at 08:13 -0700, Matthew Wilcox wrote:
    >> On Wed, Aug 12, 2009 at 11:48:27PM +0100, Hugh Dickins wrote:
    >>> But fundamentally, though I can see how this cutdown communication
    >>> path is useful to compcache, I'd much rather deal with it by the more
    >>> general discard route if we can. (I'm one of those still puzzled by
    >>> the way swap is mixed up with block device in compcache: probably
    >>> because I never found time to pay attention when you explained.)
    >>> You're right to question the utility of the current swap discard
    >>> placement. That code is almost a year old, written from a position
    >>> of great ignorance, yet only now do we appear to be on the threshold
    >>> of having an SSD which really supports TRIM (ah, the Linux ATA TRIM
    >>> support seems to have gone missing now, but perhaps it's been
    >>> waiting for a reality to check against too - Willy?).
    >> I am indeed waiting for hardware with TRIM support to appear on my
    >> desk before resubmitting the TRIM code. It'd also be nice to be able to
    >> get some performance numbers.
    >>> I won't be surprised if we find that we need to move swap discard
    >>> support much closer to swap_free (though I know from trying before
    >>> that it's much messier there): in which case, even if we decided to
    >>> keep your hotline to compcache (to avoid allocating bios etc.), it
    >>> would be better placed alongside.
    >> It turns out there are a lot of tradeoffs involved with discard, and
    >> they're different between TRIM and UNMAP.
    >> Let's start with UNMAP. This SCSI command is used by giant arrays.
    >> They want to do Thin Provisioning, so allocate physical storage to virtual
    >> LUNs on demand, and want to deallocate it when they get an UNMAP command.
    >> They allocate storage in large chunks (hundreds of kilobytes at a time).
    >> They only care about discards that enable them to free an entire chunk.
    >> The vast majority of users *do not care* about these arrays, because
    >> they don't have one, and will never be able to afford one. We should
    >> ignore the desires of these vendors when designing our software.
    > Fundamentally, unmap, trim and write_same do similar things, so
    > realistically they all map to discard in linux.
    > Ignoring the desires of the enterprise isn't an option, since they are a
    > good base for us. However, they really do need to step up with a useful
    > patch set for discussion that does what they want, so in the interim I'm
    > happy with any proposal that doesn't actively damage what the enterprise
    > wants to do with trim/write_same.

    I definitely agree - the UNMAP support and the needs of array users is a
    critical part of the solution.

    I would also dispute the contention that this is irrelevant to most
    users - even those of us who don't personally use arrays almost always
    use them indirectly since major banks, airlines, etc all use them to
    store our data :-)

    >> Solid State Drives are introducing an ATA command called TRIM. SSDs
    >> generally have an intenal mapping layer, and due to their low, low seek
    >> penalty, will happily remap blocks anywhere on the flash. They want
    >> to know when a block isn't in use any more, so they don't have to copy
    >> it around when they want to erase the chunk of storage that it's on.
    >> The unfortunate thing about the TRIM command is that it's not NCQ, so
    >> all NCQ commands have to finish, then we can send the TRIM command and
    >> wait for it to finish, then we can send NCQ commands again.
    > That's a bit of a silly protocol oversight ... I assume there's no way
    > it can be corrected?
    >> So TRIM isn't free, and there's a better way for the drive to find
    >> out that the contents of a block no longer matter -- write some new
    >> data to it. So if we just swapped a page in, and we're going to swap
    >> something else back out again soon, just write it to the same location
    >> instead of to a fresh location. You've saved a command, and you've
    >> saved the drive some work, plus you've allowed other users to continue
    >> accessing the drive in the meantime.
    >> I am planning a complete overhaul of the discard work. Users can send
    >> down discard requests as frequently as they like. The block layer will
    >> cache them, and invalidate them if writes come through. Periodically,
    >> the block layer will send down a TRIM or an UNMAP (depending on the
    >> underlying device) and get rid of the blocks that have remained unwanted
    >> in the interim.
    >> Thoughts on that are welcome.
    > What you're basically planning is discard accumulation ... it's
    > certainly closer to what the enterprise is looking for, so no objections
    > from me.
    > James

    This sounds like a good approach to me as well. I think that both TRIM
    and UNMAP use case will benefit from coalescing these discard requests,


     \ /
      Last update: 2009-08-13 20:27    [W:0.550 / U:0.868 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site