Re: Discard support (was Re: [PATCH] swap: send callback when swapslot is freed)

[Mark Lord]

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.

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