On Sun, 16 Aug 2009 15:05:30 +0100
Alan Cox [off-list ref] wrote:

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

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



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

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