[lkml]   [2012]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[MMTests] IO metadata on ext3
    Configuration:	global-dhp__io-metadata-ext3
    Benchmarks: dbench3, fsmark-single, fsmark-threaded


    While the fsmark figures look ok, fsmark in single threaded mode has
    a small number of large outliers towards the min end of the scale. The
    resulting standard deviation fuzzes results but filtering is not necessarily
    the best answer. A similar effect is visible when running in threaded
    mode except that there is clustering around some values that could be
    presented better. Arithmetic mean is unsuitable for this sort of data.

    Benchmark notes

    mkfs was run on system startup. No attempt was made to age it. No
    special mkfs or mount options were used.

    dbench3 was chosen as it's metadata intensive.
    o Duration was 180 seconds
    o OSYNC, OSYNC_DIRECTORY and FSYNC were all off

    As noted in the MMTests, dbench3 can be a random number generator
    particularly when run in asynchronous mode. Even with the limitations,
    it can be useful as an early warning system and as it's still used by
    QA teams it's still worth keeping an eye on.

    o Parallel directories were used
    o 1 Thread per CPU
    o 0 Filesize
    o 225 directories
    o 22500 files per directory
    o 50000 files per iteration
    o 15 iterations
    Single: ./fs_mark -d /tmp/fsmark-9227/1 -D 225 -N 22500 -n 50000 -L 15 -S0 -s 0
    Thread: ./fs_mark -d /tmp/fsmark-9407/1 -d /tmp/fsmark-9407/2 -D 225 -N 22500 -n 25000 -L 15 -S0 -s 0

    FSMark is a more realistic indicator of metadata intensive workloads.

    Machine: arnold
    Arch: x86
    CPUs: 1 socket, 2 threads
    Model: Pentium 4
    Disk: Single Rotary Disk
    Status: Fine

    For single clients, we're doing reasonably well. There was a big spike
    for large number of clients in 2.6.34 and to a lesser extent in
    but much of this is due to the operations taking place in memory without
    reaching disk. There were also fairness issues and the indicated throughput
    figures are far higher than the disks capabilities so I do not consider
    this to be a regression.

    There was a mild dip for 3.2.x and 3.3.x that has been recovered somewhat
    in 3.4. As this was when IO-Less Dirty Throttling got merged it is hardly
    a surprise and a dip in dbench is not worth backing that out for.

    Recent kernels appear to deal worse for large number of clients. However,
    I very strongly suspect this is due to improved fairness in IO. The
    high throughput figures are due to one client making an unfair amount
    of progress while other clients stall.

    Again, this is looking good. Files/sec has improved slightly with the
    exception of a dip in 3.2 and 3.3 which again may be due to IO-Less
    dirty throttling.

    I have a slight concern with the overhead measurements. Somewhere
    between 3.0.23 and 3.1.10 the overhead started deviating a lot more.
    Ideally this should be bisected because it difficult to blame
    IO-Less throttling with any certainity.
    IO-Less Throttling.

    Looks better but due to high deviations it's hard to be 100% sure.
    If this is of interest then the thing to do is do a proper measurement
    of whether the results are significant or not although with 15 samples
    it still will be fuzzy.

    Right now, there is little to be concerned about.

    Machine: hydra
    Arch: x86-64
    CPUs: 1 socket, 4 threads
    Model: AMD Phenom II X4 940
    Disk: Single Rotary Disk
    Status: Fine

    Very similar story to the arnold machine. Big spike in 2.6.34 and then
    drops off.

    Nothing really notable here. Deviations are too high to draw reasonable
    conclusions from. Looking at the raw results it's due to a small number
    of low outliers. These could be filtered but it would mask the fact that
    throughput is not consistent so strong justification would be required.

    Similar to fsmark-single. Figures look ok but large deviations are
    a problem Unlike the single-threaded case the raw data shows that we
    cluster around two points that are very far apart from each other. It
    is worth investigating if this can be presented in some sensible
    manner such as k-means clustering because arithmetic mean with this
    sort of data is crap.

    Machine: sandy
    Arch: x86-64
    CPUs: 1 socket, 8 threads
    Model: Intel Core i7-2600
    Disk: Single Rotary Disk
    Status: Fine

    Same as the other two complete with spikes.

    Other than overhead going crazy in 3.2 there is nothing notable either.
    As with hydra, there are a small number of outliers that result in large

    Similar to hydra. Figures look basically ok but deviations are high with
    some clustering going on.

    Mel Gorman
    SUSE Labs

     \ /
      Last update: 2012-06-29 14:01    [W:0.032 / U:20.488 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site