On Sat, 15 Aug 2009 08:55:17 -0500 James Bottomley <James.Bottomley@xxxxxxx> 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 ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
