Re: Pluggable Disk Schedulers in GEOM

On Fri, Jan 05, 2007 at 06:46:21PM +0100, lulf_at_stud.ntnu.no wrote:
> Siterer Ivan Voras <ivoras_at_fer.hr>:
> 
> > Poul-Henning Kamp wrote:
> >> In message <20070105123127.gnk0v58p44488g48_at_webmail.ntnu.no>,   
> >> lulf_at_stud.ntnu.no
> >>  writes:
> >>
> >>
> >>> However, I will look into this a bit more just out of curiosity, and =20
> >>> do some actual test on how this can affect performance in the =20
> >>> scenarios you describe. And thanks for the tips!
> >>
> >> Keep us posted, I am interested in your results even if they don't
> >> show anything remarkable.
> >
> > Have both of you seen this:
> > http://wikitest.freebsd.org/Hybrid
> 
> Yes, this was what I was using as a basis.
> I forgot to paste the link, but I assumed people would know about it  
> since it was referred to on the "ideas" page that I was referring to :)
> 
> However, there was little actual test-result on that page, which would  
> be nice to have.

i can partly comment on the test results.

Once you manage to make queues build up at the scheduler
(using AIO and multiple outstanding requests per process etc.)
we were able to achieve fairness whith the proportional-fair
scheduler, whereas the elevator (standard scheduler) gave a lot
more bandwidth to the process who started first.

However there are a lot of conditions to make this happen:
essentialy, anything that prevents queues to build up at the
point where the scheduler is invoked will render the scheduler
useless. Among these:

- requests are made one at a time (e.g. without using AIO,
  or slower than the disk can serve them);

- the ATA driver in 6.x/7.x does not queue bio's but moves them
  immediately to the layer below, where there is actually queueing;

- locking at a higher level (e.g. the FS code) might enforce an
  ordering on requests before these are sent to the disk unit

and so on.

Also, there is a class of schedulers (non-work-conserving)
that are not supported by this architecture, for the reasons explained   
in the wiki, and this is a shame as it is a very promising one
judging by the literature.

Essentially, a process doing e.g. a 'cvs checkout' on a large
tree will still kill the performance of your disk no matter     
which scheduler you are using (elevator, hybrid, the dumb one that
we wrote as an example). The reasons, i suspect, are a mixture
of the ones described above.

	cheers
	luigi