Re: Time sliced CFQ io scheduler

From: Prakash K. Cheemplavam
Date: Fri Dec 03 2004 - 04:39:55 EST

Jens Axboe schrieb:
On Fri, Dec 03 2004, Prakash K. Cheemplavam wrote:

Jens Axboe schrieb:

On Thu, Dec 02 2004, Prakash K. Cheemplavam wrote:


0 3 3080 2208 1156 817712 0 0 3592 75624 1326 2289 1 36 0 63
0 3 3080 2664 1156 818240 0 0 5124 15692 1302 992 1 18 0 81
0 3 3080 2580 1160 815832 0 0 4356 155792 1375 1064 1 39 0 60
0 3 3080 2472 1160 817124 0 0 3076 100852 1345 1138 1 23 0 76
2 4 3080 2836 1148 816228 0 0 3336 100412 1352 1379 1 47 0 52
0 4 3080 2708 1144 815964 0 0 3844 48908 1343 871 1 25 0 74
0 3 3080 2748 1152 815984 0 0 3332 71996 1338 843 1 27 0 72


Can you try with the patch that is in the parent of this thread? The
above doesn't look that bad, although read performance could be better
of course. But try with the patch please, I'm sure it should help you
quite a lot.


It actually got worse: Though the read rate seems accepteble, it is not, as interactivity is dead while writing. I cannot start porgrammes, other programmes which want to do i/o pretty much hang. This is only while writing. While reading there is no such problem.


Interesting, thanks for testing. I'll run some tests here as well, so
far only the cases mentioned yesterday have been tested.

BTW, in case it is misread: Above (except the io performance as such) is
no regression: The other schedulers behave the same on my system.


You could try and bumb the slice period. But I'll experiment and see
what happens. What is your test case?

[slice bumping] Uhm, is it doable via proc? I haven't seen text docs to
your patch and I am not good at kernel code ;-)

My test case was apkm's one: write 1gb continuesly and try to cat a
several gb big file to /dev/null. At the same time I checked starting
other apps/using my emial client...

For me the problem in mainline has been since quite some time...checked till kernel 2.6.7.

Prakash

Attachment: signature.asc
Description: OpenPGP digital signature