Linus Torvalds (torvalds@linux-foundation.org) on 1/19/11 wrote:
---------------------------
>Aaron Spink (aaronspink@notearthlink.net) on 1/19/11 wrote:
>>
>>It's bogus. There is currently absolutely no reason to support free(), not on
>>OS's, not on anything else. The whole feature is totally broken.
>>
>>Does that sound kinda stupid?
>
>It does.
>
>>Because it basically what you said.
>
>No it isn't. Not even close. You can try to make an analogy,
>but the fact is, TRIM and "free()" have absolutely zero
>points in common.
>
>In many ways, TRIM is closer to "unmap()" or a shrinking
>brk(), and if you actually were to look at most malloc
>libraries, they will go to quite some length to never
>actually use unmap or shrink the heap using brk().
>
>Why? Because it's damn slow. The libraries know that it's
>better to use do their own freelist management, and rather
>than give the memory back to the OS, just re-use it.
>
>The exact same case is true of trim. In normal operation,
>you're better off just managing and re-using the disk
>yourself, rather than wasting your time informing the
>disk about your usage patterns.
>
>That is a closer analogy. Don't do it at run-time,
>because there is absolutely no reason to do so. You can
>do it for when somebody frees gigabytes of data in one go,
>but you're much more likely to do it offline (ie when the
>process exits and is no longer doing any malloc/free at
>all).
>
>And yes, that results in the OS/disk now knowing which
>pages/sectors are necessarily free, and when it needs
>more memory/disk it will end up paging/doing gc. But that
>is still much more efficient than doing it at every
>free/delete. Despite the fact that in theory you might
>be moving memory/disk around unnecessarily.
>
>Btw, while I think my munmap analogy is much better than
>your totally idiotic free() one, I also wouldn't claim that
>my analogy is all that great either. The use cases are
>different, and you'd never expect to have to worry about
>unmap/brk failing the way TRIM fails.
>
>Although to some degree the performance issues are actually
>somewhat the same (ie some OS'es are really slow at
>VM changes, others not so much, so the cost of munmap()
>will vary by orders of magnitude).
>
>Linus


What you are talking about Linus is how to USE TRIM.
And yet you seem to be lambasting its existance.

The fact is that TRIM is critical for flash use in a way that it is not for disk storage. Of course you do not need to trim as you deallocate, and your comparison with sbrk versus free is right on the money, however you still need it!

Without trim, a disk MUST assume any sector ever written is still required, and therefore to do write leveling it must MOVE rather than REALLOCATE that data, at a great performance cost. It also cannot pre-clear that area.

TRIM data gives a flash controller very valuable information to run more optimally.

The use of TRIM can be improved, but that does not mean it should not be used - it will significantly extend the life of even the best flash/controller combination as it removes data relocation requirements, and they are expensive.