lkml.org 
[lkml]   [2009]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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@tmr.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.




    \
     
     \ /
      Last update: 2009-08-17 18:35    [W:2.784 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site