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@xxxxxxx>
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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
