Messages in this thread | | | Subject | Re: performance "regression" in cfq compared to anticipatory, deadline and noop | From | Kasper Sandberg <> | Date | Tue, 13 May 2008 15:51:04 +0200 |
| |
On Tue, 2008-05-13 at 14:20 +0200, Jens Axboe wrote: > On Sun, May 11 2008, Kasper Sandberg wrote: > > On Sun, 2008-05-11 at 14:14 +0100, Daniel J Blueman wrote: > > > I've been experiencing this for a while also; an almost 50% regression > > > is seen for single-process reads (ie sync) if slice_idle is 1ms or > > > more (eg default of 8) [1], which seems phenomenal. <snip> > > > > Thisd would appear to be quite a considerable performance difference. > > Indeed, that is of course a bug. The initial mail here mentions this as > a regression - which kernel was the last that worked ok?
I am afraid i cannot exactly tell you..
But i do have some additional information for you.
I have a server running with identical disk to mine, however, with an older intel ahci controller..
This one gets 80mb/s with cfq, and 100mb/s with anticipatory/deadline/noop with hdparm..
This server is running debian stable with a .18 kernel. I am sad to say however, that i will be unable to do any testing on this box, since it is a production server, and i can not shut it down.
haltek:~/blktrace# ./blktrace /dev/sda BLKTRACESETUP: Inappropriate ioctl for device Failed to start trace on /dev/sda
However, on the box where you saw the previous numbers, i sure will be able to provide you with the data you need.
i expect to get around to doing this this afternoon, or tonight at ~02:00 (im GMT+1).
> > If someone would send me a blktrace of such a slow run, that would be > nice. Basically just do a blktrace /dev/sda (or whatever device) while > doing the hdparm, preferably storing output files on a difference > device. Then send the raw sda.blktrace.* files to me. Thanks! >
| |