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

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 ?

Alan

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