Messages in this thread | | | Date | Sat, 15 Jul 2006 19:46:01 +0200 | From | Jens Axboe <> | Subject | Re: [PATCHSET] 0/15 IO scheduler improvements |
| |
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/
| |