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