Re: [PATCHSET] 0/15 IO scheduler improvements

[Jens Axboe <axboe@suse.de>]

On Sat, Jul 15 2006, Al Boldi wrote:
> Jens Axboe wrote:
> > On Fri, Jul 14 2006, Al Boldi wrote:
> > > Jens Axboe wrote:
> > > > On Thu, Jul 13 2006, Al Boldi wrote:
> > > > > Jens Axboe wrote:
> > > > > > This is a continuation of the patches posted yesterday, I
> > > > > > continued to build on them. The patch series does:
> > > > > >
> > > > > > - Move the hash backmerging into the elevator core.
> > > > > > - Move the rbtree handling into the elevator core.
> > > > > > - Abstract the FIFO handling into the elevator core.
> > > > > > - Kill the io scheduler private requests, that require
> > > > > > allocation/free for each request passed through the system.
> > > > > >
> > > > > > The result is a faster elevator core (and faster IO schedulers),
> > > > > > with a nice net reduction of kernel text and code as well.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Your efforts are much appreciated, as the current situation is a bit
> > > > > awkward.
> > > >
> > > > It's a good step forward, at least.
> > > >
> > > > > > If you have time, please give this patch series a test spin just
> > > > > > to verify that everything still works for you. Thanks!
> > > > >
> > > > > Do you have a combo-patch against 2.6.17?
> > > >
> > > > Not really, but git let me generate one pretty easily. It has a few
> > > > select changes outside of the patchset as well, but should be ok. It's
> > > > not tested though, should work but the rbtree changes needed to be
> > > > done additionally. If it boots, it should work :-)
> > >
> > > patch applies ok
> > > compiles ok
> > > panics on boot at elv_rb_del
> > > patch -R succeeds with lot's of hunks
> >
> > So I most likely botched the rbtree conversion, sorry about that. Oh, I
> > think it's a silly reverted condition, can you try this one?
> 
> Thanks!
> 
> patch applies ok
> compiles ok
> boots ok
> patch -R succeeds with lot's of hunks
> 
> Tried it anyway, and found an improvement only in cfq, where :
> echo 512 > /sys/block/hda/queue/max_sectors_kb
> gives full speed for 5-10 sec then drops to half speed
> other scheds lock into half speed
> echo 192 > /sys/block/hda/queue/max_sectors_kb
> gives full speed for all scheds

Not sure what this all means (full speed for what?) The patchset mainly
focuses on optimizing the elevator core and schedulers, it wont give a
speedup unless your storage hardware is so fast that you are becoming
CPU bound. Since you are applying to 2.6.17, there are some CFQ changes
that do introduce behavioural changes.

You should download

http://brick.kernel.dk/snaps/blktrace-git-20060706102503.tar.gz

and build+install it, then do:

- blktrace /dev/hda
- run shortest test that shows the problem
- ctrl-c blktrace

tar up the hda.* output from blktrace and put it somewhere where I can
reach it and I'll take a look.

-- 
Jens Axboe

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