lkml.org 
[lkml]   [2009]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Bug 12309] Large I/O operations result in slow performance and high iowait times
    From
    Date

    > --- Comment #412 from Thomas Pilarski <thomas.pi@arcor.de> 2009-11-01 21:28:24 ---
    > Created an attachment (id=23618)
    > --> (http://bugzilla.kernel.org/attachment.cgi?id=23618)
    > Simple sleeper test case
    >
    > As this bug occurs more permanent while working in an virtual machine or while
    > using java and I still think, that's this is a process scheduler bug (or
    > something related). Here another test case, which shows the suspected
    > behaviour. As there are many system calls while using a virtual machine, I have
    > tries to find an equal test. The test case just sleeps for 1__s and measures the
    > time difference of the usleep operation. I am using such many of the usleep
    > operations, as the problems does not occur deterministic and I tried to catch
    > as many as possibly occurrences.
    >
    > I have run this test case on three machines. The first one was a Core2 Duo with
    > a first generation SDD (OCZ Core Series) with a poor write performance and on a
    > Ubuntu kernel 2.6.31-14-generic. The partitions are block aligned. I have run
    > this test, while my wife was using firefox. Every time, she was submitting
    > something and firefox is using sqlite for writing the history, there was a high
    > latency for the sleep test.
    >
    > Timediff 7629094: 16.80ms Total: 61.12ms
    > Timediff 7629100: 18.82ms Total: 93.68ms
    > Timediff 7629101: 19.96ms Total: 113.54ms
    > Timediff 7629102: 19.98ms Total: 133.43ms
    > Timediff 7629103: 19.97ms Total: 153.31ms
    > Timediff 7629104: 20.00ms Total: 173.24ms
    > Timediff 7629105: 19.96ms Total: 193.09ms
    > Timediff 7629106: 20.02ms Total: 213.02ms
    > Timediff 7629107: 19.94ms Total: 232.86ms
    > Timediff 7636162: 16.40ms Total: 34.44ms
    > Timediff 7636164: 19.90ms Total: 64.00ms
    >
    > While the duration of 100 usleep should be somewhere between 10ms and 20ms, 10
    > usleep(1) takes more than 200ms. This behaviour is reproducible.

    Can you please try the latest -rc? I spent the day trying to coax a
    latency spike out of -tip, including thumping disk with dd, mysql+oltp
    rw test et al, and failed.

    -Mike



    \
     
     \ /
      Last update: 2009-11-02 16:59    [W:0.024 / U:3.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site