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: <4A8890B8.6070409@anonymous.org.uk>
Date:	Mon, 17 Aug 2009 00:05:28 +0100
From:	John Robinson <john.robinson@...nymous.org.uk>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Arjan van de Ven <arjan@...radead.org>,
	James Bottomley <James.Bottomley@...e.de>,
	Mark Lord <liml@....ca>, 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 16/08/2009 20:29, Alan Cox wrote:
>> trim is mostly for ssd's though, and those tend to not have the "goes
>> for a hike" behavior as much......
> 
> Bench one.
> 
>> I wonder if it's worse to batch stuff up, because then the trim itself
>> gets bigger and might take longer.....
> 
> They seem to implement a sort of async single threaded trim, which can
> only have one outstanding trim at a time.

I'm slightly out of my depth here, but: if a single TRIM is issued, 
which apparently returns quickly, can one then revert to issuing 
ordinary commands like reads and writes and have them complete as 
quickly as they normally do, or does any following command have to wait 
until the trim completes? This could be useful if it turned out we won't 
stall these devices as long as we don't issue more than one TRIM every 
few seconds; we could keep a TRIM coalesce queue down to being (say) 5 
seconds long (or at least, a configurable small number of seconds).

Cheers,

John.
--
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/