On Fri, Aug 14, 2009 at 6:30 PM, Greg Freemyer<greg.freemyer@xxxxxxxxx> wrote: > On Fri, Aug 14, 2009 at 8:19 PM, Chris Worley<worleys@xxxxxxxxx> wrote: >> On Fri, Aug 14, 2009 at 5:45 PM, Matthew Wilcox<matthew@xxxxxx> wrote: >>> On Fri, Aug 14, 2009 at 05:21:32PM -0600, Chris Worley wrote: >>>> Sooner is better than waiting to coalesce. The longer an LBA is >>>> inactive, the better for any management scheme. If you wait until >>>> it's reused, you might as well forgo the advantages of TRIM/UNMAP. If >>>> a the controller wants to coalesce, let it coalesce. >>> >>> I'm sorry, you're wrong. There is a tradeoff point, and it's different >>> for each drive model. Sending down a steady stream of tiny TRIMs is >>> going to give terrible performance. >> >> Sounds like you might be using junk for a device? >> >> For junk, a little coalescing may be warranted... like in the I/O >> schedular, but no more than 100usecs wait before posting, or then you >> effect high performing devices too. >> >> Chris > > Why? > > AIUI, on every write a high performing device allocates a new erase > block from its free lists, writes to it, and puts the now unused erase > block on the free list. So erase blocks are 512 bytes (if I write 512 bytes, an erase block is now freed)? Not true. > That erase block becomes available for reuse > some milliseconds later. > > As long as the SSD has enough free erase blocks to work with I see no > disadvantage in delaying a discard by minutes, hours or days in most > cases. The exception is when the filesystem is almost full and the > SSD is short of erase blocks to work with. That "exception..." is another good reason why. > > In that case it will want to get as many free erase blocks as it can > as fast as it can get them. Exactly. Chris > > Greg > -- 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
