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 [off-list ref] wrote:

quoted

On Sat, 15 Aug 2009 08:55:17 -0500
James Bottomley [off-list ref] wrote:

quoted

On Sat, 2009-08-15 at 09:22 -0400, Mark Lord wrote:

quoted

James Bottomley wrote:

quoted

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

James


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>