Re: [Bug 12309] Large I/O operations result in slow performanceand high iowait times

[Mike Galbraith]

> --- Comment #412 from Thomas Pilarski <thomas.pi@xxxxxxxx>  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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/