Re: unconditional discard calls in the swap code

[Christoph Hellwig <hch@lst.de>]

On Fri, Oct 30, 2009 at 05:26:18PM +0000, Hugh Dickins wrote:
> Yes, in practice TRIM seems a huge disappointment: is there a device on
> which it is really implemented, and not more trouble than it's worth?
> 
> I'd been waiting for OCZ to get a Vertex 1.4* firmware out of Beta
> before looking at swap discard again; but even then, the Linux ATA
> support is still up in the air, so far as I know.

I've tied it up now for libata, and testing with the releases OCZ 1.4
firmware.  Haven't tested anything else yet except for my own
implementations of TRIM and WRITE SAME in qemu which are a lot faster
than real hardware.

> 
> You don't mention swap's discard of the whole partition (or all
> extents of the swapfile) at swapon time: do you believe that usage
> is okay to retain?  Is it likely on some devices to take so long,
> that I ought to make it asynchronous?

The use on swapon seems fine - we've also added support to discard
on mkfs which is generally fast enough - the existing implementations
seem to have mostly constant overhead, the more blocks your discard,
the better.

> Assuming that initial swap discard is good, I wonder whether just
> to revert the discard of swap clusters for now: until such time as
> we find devices (other than mtd) that can implement it efficiently.
> 
> If we do retain the discard of swap clusters, under something more
> than an #if 0, any ideas for what I should make it conditional upon?

add a sysctl / sysfs tunable for it?  For all filesystems we now have
patches pending to require and -o discard option to use it, which will
be quite nessecary for 2.6.33 where all the block layer / scsi layer /
libata support will fall into place.

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