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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1250446047.3856.273.camel@mulgrave.site>
Date:	Sun, 16 Aug 2009 13:07:27 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	Mark Lord <liml@....ca>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Chris Worley <worleys@...il.com>,
	Matthew Wilcox <matthew@....cx>,
	Bryan Donlan <bdonlan@...il.com>, david@...g.hm,
	Greg Freemyer <greg.freemyer@...il.com>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Nitin Gupta <ngupta@...are.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org,
	Linux RAID <linux-raid@...r.kernel.org>
Subject: Re: Discard support (was Re: [PATCH] swap: send callback when swap
 slot is freed)

On Sun, 2009-08-16 at 12:32 -0400, Mark Lord wrote:
> James Bottomley wrote:
> >
> > For SSDs, the FTL has to have a separate operation: erase.  Now, one
> > could see the correct implementation simply moving the sectors from the
> > in-use list to the to be cleaned list and still do the cleaning in the
> > background: that would be constant cost (but, again, likely expensive).
> > Of course, if SSD vendors decided to erase on the spot when seeing TRIM,
> > this wouldn't be true ...
> ..
> 
> The SSDs based upon the Indilinx Barefoot controller appear to do
> the erase on the spot, along with a fair amount of garbage collection.

Groan.  I'm with Jim on this one:  If trim is going to cost us in terms
of current fs performance, it's likely not worth it.  The whole point of
a TRIM/UNMAP is that we're just passing hints about storage use.  If the
drives make us pay the penalty of acting on the hints as we pass them
in, we may as well improve performance just by not hinting.  Or at least
it's detrimental hinting in real time.

So I think we've iterated to the conclusion that it has to be a user
space process which tries to identify idle periods and begin trimming.

> The overhead does vary by size of the TRIM operation (number of sectors
> and extents), but even a single-sector TRIM has very high overhead.

So it's something like X + nY (n == number of sectors).  If X is large,
it still argues for batching .. it's just there's likely an upper bound
to the batch where the benefit is no longer worth the cost.

> Samsung also now has SSDs at retail with TRIM.
> I don't have one of those here.

Heh, OS writers not having access to the devices is about par for the
current course.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/