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]
Date:	Mon, 17 Aug 2009 12:30:46 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Mark Lord <liml@....ca>
CC:	Theodore Tso <tytso@....edu>,
	Arjan van de Ven <arjan@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	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)

Mark Lord wrote:
> Mark Lord wrote:
> ..
>> As you can see, we're now into the 100 millisecond range
>> for successive TRIM-followed-by-TRIM commands.
>>
>> Those are all for single extents.  I will follow-up with a small
>> amount of similar data for TRIMs with multiple extents.
> ..
>
> Here's the exact same TRIM ranges, but issued with *two* extents
> per TRIM command, and again *without* the "sleep 1" between them:
>
> Beginning TRIM operations..
> Trimming 2 free extents encompassing 686 sectors (0 MB)
> Trimming 2 free extents encompassing 236 sectors (0 MB)
> Trimming 2 free extents encompassing 2186 sectors (1 MB)
> Trimming 2 free extents encompassing 2206 sectors (1 MB)
> Trimming 2 free extents encompassing 1494 sectors (1 MB)
> Trimming 2 free extents encompassing 1086 sectors (1 MB)
> Trimming 2 free extents encompassing 1658 sectors (1 MB)
> Trimming 2 free extents encompassing 14250 sectors (7 MB)
> Done.
> [ 1528.761626] ata_qc_issue: ATA_CMD_DSM starting
> [ 1528.761825] trim_completed: ATA_CMD_DSM took 419952 cycles
> [ 1528.807158] ata_qc_issue: ATA_CMD_DSM starting
> [ 1528.919035] trim_completed: ATA_CMD_DSM took 241772908 cycles
> [ 1528.956048] ata_qc_issue: ATA_CMD_DSM starting
> [ 1529.068536] trim_completed: ATA_CMD_DSM took 243085505 cycles
> [ 1529.156661] ata_qc_issue: ATA_CMD_DSM starting
> [ 1529.266377] trim_completed: ATA_CMD_DSM took 237098927 cycles
> [ 1529.367212] ata_qc_issue: ATA_CMD_DSM starting
> [ 1529.464676] trim_completed: ATA_CMD_DSM took 210619370 cycles
> [ 1529.518619] ata_qc_issue: ATA_CMD_DSM starting
> [ 1529.630444] trim_completed: ATA_CMD_DSM took 241654712 cycles
> [ 1529.739335] ata_qc_issue: ATA_CMD_DSM starting
> [ 1529.829826] trim_completed: ATA_CMD_DSM took 195545233 cycles
> [ 1529.958442] ata_qc_issue: ATA_CMD_DSM starting
> [ 1530.028356] trim_completed: ATA_CMD_DSM took 151077251 cycles
>
> Next, with *four* extents per TRIM:
>
> Beginning TRIM operations..
> Trimming 4 free extents encompassing 922 sectors (0 MB)
> Trimming 4 free extents encompassing 4392 sectors (2 MB)
> Trimming 4 free extents encompassing 2580 sectors (1 MB)
> Trimming 4 free extents encompassing 15908 sectors (8 MB)
> Done.
> [ 1728.923119] ata_qc_issue: ATA_CMD_DSM starting
> [ 1728.923343] trim_completed: ATA_CMD_DSM took 460590 cycles
> [ 1728.975082] ata_qc_issue: ATA_CMD_DSM starting
> [ 1729.087266] trim_completed: ATA_CMD_DSM took 242429200 cycles
> [ 1729.170167] ata_qc_issue: ATA_CMD_DSM starting
> [ 1729.282718] trim_completed: ATA_CMD_DSM took 243229428 cycles
> [ 1729.382328] ata_qc_issue: ATA_CMD_DSM starting
> [ 1729.481364] trim_completed: ATA_CMD_DSM took 214012942 cycles
>
> And with *eight* extents per TRIM:
> Beginning TRIM operations..
> Trimming 8 free extents encompassing 5314 sectors (3 MB)
> Trimming 8 free extents encompassing 18488 sectors (9 MB)
> Done.
> [ 1788.289669] ata_qc_issue: ATA_CMD_DSM starting
> [ 1788.290247] trim_completed: ATA_CMD_DSM took 1228539 cycles
> [ 1788.327223] ata_qc_issue: ATA_CMD_DSM starting
> [ 1788.440490] trim_completed: ATA_CMD_DSM took 244773243 cycles
>
> And finally, with everything in a single TRIM:
>
> Beginning TRIM operations..
> Trimming 16 free extents encompassing 23802 sectors (12 MB)
> Done.
> [ 1841.561147] ata_qc_issue: ATA_CMD_DSM starting
> [ 1841.563217] trim_completed: ATA_CMD_DSM took 4458480 cycles
>
> Notice how the first TRIM of each group above shows an artificially
> short completion time, because the firmware seems to return "done"
> before it's really done.  Subsequent TRIMs seem to have to wait
> for the previous one to really complete, and thus give more reliable
> timing data for our purposes.

I assume that it really is artificial, rather than the device really 
being ready for another operation (other than another TRIM). I lack the 
hardware, but the test would be the time to complete a read, trim and 
read, and two trim and read operations. Just my thought that the TRIM in 
progress may only block the next TRIM, rather than other operations.

-- 
bill davidsen <davidsen@....com>
  CTO TMR Associates, Inc

"You are disgraced professional losers. And by the way, give us our money back."
    - Representative Earl Pomeroy,  Democrat of North Dakota
on the A.I.G. executives who were paid bonuses  after a federal bailout.


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