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

    For the most part the figures look ok currently. However a number of
    tests show that we have declined since 3.0 in a number of areas. Some
    machines show that there were performance drops in the 3.2 and 3.3
    kernels that have not being fully recovered.

    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 but fsmark has declined since 3.0

    For single clients, we're doing reasonably well and this has been consistent
    with each release.

    This is not as happy a story. Variations are quite high but 3.0 was a
    reasonably good kernel and we've been declining ever since with 3.4
    being marginally worse than 2.6.32.

    The trends are very similar to fsmark-single. 3.0 was reasonably good
    but we have degraded since and are at approximately 2.6.32 levels.

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

    Unlike arnold, this is looking good with solid gains in most kernels
    for the single-threaded case. The exception was 3.2.9 which saw a
    a big dip that was recovered in 3.3. For higher number of clients the
    figures still look good. It's not clear why there is such a difference
    between arnold and hydra for the single-threaded case.

    This is very similar to arnold in that 3.0 performed best and we have
    declined since back to more or less the same level as 2.6.32.

    Performance here is flat in terms of throughput. 3.4 recorded much higher
    overhead but it is not clear if this is a cause for concern.

    Machine: sandy
    Arch: x86-64
    CPUs: 1 socket, 8 threads
    Model: Intel Core i7-2600
    Disk: Single Rotary Disk
    Status: Fine but there have been recent declines

    Like hydra, this is looking good with solid gains in most kernels for the
    single-threaded case. The same dip in 3.2.9 is visible but unlikely hydra
    it was not recovered until 3.4. Higher number of clients generally look
    good as well although it is interesting to see that the dip in 3.2.9 is
    not consistently visible.

    Overhead went crazy in 3.3 and there is a large drop in files/sec in
    3.3 as well.

    The trends are similar to the single-threaded case. Looking reasonably
    good but a dip in 3.3 that has not being recovered and overhead is

    Mel Gorman
    SUSE Labs

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