[lkml]   [2010]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Performance regression in scsi sequential throughput (iozone) due to "e084b - page-allocator: preserve PFN ordering when __GFP_COLD is set"

    Mel Gorman wrote:
    > On Mon, Feb 08, 2010 at 03:01:16PM +0100, Christian Ehrhardt wrote:
    >> Mel Gorman wrote:
    >>> On Fri, Feb 05, 2010 at 04:51:10PM +0100, Christian Ehrhardt wrote:
    >>>> I'll keep the old thread below as reference.
    >>>> After taking a round of ensuring reproducibility and a pile of new
    >>>> measurements I now can come back with several new insights.
    >>>> FYI - I'm now running iozone triplets (4, then 8, then 16 parallel
    >>>> threads) with sequential read load and all that 4 times to find
    >>>> potential noise. But since I changed to that load instead of random
    >>>> read wit hone thread and ensuring the most memory is cleared (sync +
    >>>> echo 3 > /proc/sys/vm/drop_caches + a few sleeps) . The noise is now
    >>>> down <2%. For detailed questions about the setup feel free to ask me
    >>>> directly as I won't flood this thread too much with such details.
    >>> Is there any chance you have a driver script for the test that you could send
    >>> me? I'll then try reproducing based on that script and see what happens. I'm
    >>> not optimistic I'll be able to reproduce the problem because I think
    >>> it's specific to your setup but you never know.
    >> I don't have one as it runs in a bigger automated test environment, but
    >> it is easy enough to write down something comparable.
    > I'd appreciate it, thanks.

    Testing of your two patches starts in a few minutes, thanks in advance.

    Here the info how to execute the core of the test - I cross fingers that anyone else can reproduce it that way :-)

    I use it in a huge automation framework which takes care of setting up the system, disks, gathering statistics and so on, but it essentially comes down to something simple like that:

    # reboot your system with 256m
    # attach 16 disks (usually up to 64, but 16 should be enough to show the issue)
    # mount your disks at /mnt/subw0, /mnt/subw1, ...
    for i in 4 8 16 4 8 16 4 8 16 4 8 16
    sync; sleep 10s; echo 3 > /proc/sys/vm/drop_caches; sleep 2s;
    iozone -s 2000m -r 64k -t $i -e -w -R -C -i 0 -F /mnt/subw0 /mnt/subw1 /mnt/subw2 /mnt/subw3 /mnt/subw4 /mnt/subw5 /mnt/subw6 /mnt/subw7 /mnt/subw8 /mnt/subw9 /mnt/subw10 /mnt/subw11 /mnt/subw12 /mnt/subw13 /mnt/subw14 /mnt/subw15
    sync; sleep 10s; echo 3 > /proc/sys/vm/drop_caches; sleep 2s;
    iozone -s 2000m -r 64k -t $i -e -w -R -C -i 1 -F /mnt/subw0 /mnt/subw1 /mnt/subw2 /mnt/subw3 /mnt/subw4 /mnt/subw5 /mnt/subw6 /mnt/subw7 /mnt/subw8 /mnt/subw9 /mnt/subw10 /mnt/subw11 /mnt/subw12 /mnt/subw13 /mnt/subw14 /mnt/subw15
    # while we could reduce the number of writes to one 16 thread write I use it that way as it is more similar to our original load (makes no difference anyway)


    Grüsse / regards, Christian Ehrhardt
    IBM Linux Technology Center, Open Virtualization
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-02-09 07:27    [W:0.024 / U:2.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site