Re: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed)

On Fri, Aug 14, 2009 at 8:38 PM, Chris Worley[off-list ref] wrote:

On Fri, Aug 14, 2009 at 6:30 PM, Greg Freemyer[off-list ref] wrote:

quoted

On Fri, Aug 14, 2009 at 8:19 PM, Chris Worley[off-list ref] wrote:

quoted

On Fri, Aug 14, 2009 at 5:45 PM, Matthew Wilcox[off-list ref] wrote:

quoted

On Fri, Aug 14, 2009 at 05:21:32PM -0600, Chris Worley wrote:

quoted

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.

Seriously, how do you  know?  Are you under NDA?

The write paper I read about typical SSD design described a partial
erase block write as:

Internal logic/micro-controller performs:

Read erase block, modify erase block, allocate new erase block, write
new erase block, free now unused old erase block, old erase block
added to a hardware erase queue the performs the actual erase in the
background at the relatively slow speed of multiple milliseconds..

The purpose of the trim/discard command being to allow the ssd to have
enough free erase blocks ready to go that the writes don't have to
stall while they wait for a erase block to pop out of the erase queue.

Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html