Re: Pluggable Disk Scheduler Project



From: Ulf Lilleengen <lulf@xxxxxxxxxxxx>
Date: Wed, Oct 17, 2007 03:09:35PM +0200

On ons, okt 17, 2007 at 02:19:07 +0200, Fabio Checconi wrote:
Maybe I've not enough experience/knowledge of the driver subsystem,
[...]
If you look at it, Hybrid is just a generalization of the existing
bioq_* API already defined. And this API is used by GEOM classes _before_
device drivers get the requests AFAIK.


I looked at the Hybrid code, but I don't think that the bioq_*
family of calls can be the right place to start, for the problems
experienced during the Hybrid development with locking/anticipation
and because you can have the same request passing through multiple
bioqs during its path to the device (e.g., two stacked geoms using
two different bioqs and then a device driver using bioq_* to organize
its queue, or geoms using more than one bioq, like raid3; I think
the complexity can become unmanageable.) One could even think to
configure each single bioq in the system, but things can get very
complex in this way.


For a simple example on a driver, the md-driver might be a good place to
look. Note that I have little experience and knowledge of the driver
subsystem myself.


I'll take a look, thanks.


Also note (from the Hybrid page):
* we could not provide support for non work-conserving schedulers, due to a
[...]

This certainly argues for having this in the GEOM layer, but perhaps it's
possible to change the assumtions done in some drivers? The locking issue
should perhaps be better planned though, and an audit of the driver disksort
code is necessary.


I need some more time to think about that :)


Also:
* as said, the ATA driver in 6.x/7.x moves the disksort one layer below the
one we are working at, so this particular work won't help on ATA-based 6.x
machines.
We should figure out how to address this, because the work done at that
layer is mostly a replica of the bioq_*() API.

So, I see this can get a bit messy thinking of that the ATA drivers does
disksorts on its own, but perhaps it would be possible to fix this by letting
changing the general ATA driver to use it's own pluggable scheduler.

Anyway, I shouldn't demand that you do this, especially since I don't have
any code or anything to show to, and because you decide what you want to do.

I still cannot say if a GEOM scheduler is better than a scheduler
put at a lower level, or if the bioq_* interface is better than any
other alternative, so your suggestions are welcome. Moreover I'd
really like to discuss/work together, or at least do things with
some agreement on them. If I'll have the time to experiment with
more than one solution I'll be happy to do that.


However, I'd hate to see the Hybrid effort go to waste :) I was hoping some
of the authors of the project would reply with their thoughts, so I CC'ed
them.

Well, the work done on Hybrid had also interesting aspects from
the algorithm side... but that's another story...

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Pluggable Disk Scheduler Project
    ... device drivers get the requests AFAIK. ... I looked at the Hybrid code, but I don't think that the bioq_* ... Note that I have little experience and knowledge of the driver ...
    (freebsd-hackers)
  • Re: Modularize kernel
    ... One of the biggest concerns I have with moving towards a heavily modularized default kernel is that we may find we need to explore improving our automatic loading of modules. ... For example, if we want to de-populate the base kernel with respect to device drivers, which take up quite a lot of space, we'll want to look both at how to handle early boot, and later loading if hardware turns up -- issues we've largely avoided by virtue of compiling them in. ... I'm not sure I have a clear understanding of the requirements from the device driver side -- on the general service side, it's fairly straight forward because you simply say "If you want this service, load this module", or in the case of management tools, the module is loaded on demand by the management tool. ...
    (freebsd-arch)
  • device driver questions
    ... currently i am reading "linux device drivers" and i was up to create ... after registering the device driver with register_chrdev i expect to ... May 3 17:39:57 mond kernel: can'n unregister scull ...
    (comp.os.linux.development.system)
  • Re: Linux development kit
    ... where I can play around developing my own device drivers for Ethernet, ... Have you ever felt teased when driver developers of other operating ... WA, USA, I'm proud to announce the first release of the Linux Device ...
    (comp.os.linux.embedded)
  • Re: Device Drivers For Different IO Bus architectures
    ... I am trying to find out some details about writing device drivers. ... Is writing a driver to it on a unix / linux system be different If so ... Bus as required and if the interface to the layer2 / firm ware is kept ...
    (comp.arch.embedded)