Re: Pluggable Disk Scheduler Project
- From: Fabio Checconi <fabio@xxxxxxxxxxx>
- Date: Wed, 17 Oct 2007 16:39:54 +0200
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"
- Follow-Ups:
- Re: Pluggable Disk Scheduler Project
- From: Bruno Tavares
- Re: Pluggable Disk Scheduler Project
- References:
- Pluggable Disk Scheduler Project
- From: Fabio Checconi
- Re: Pluggable Disk Scheduler Project
- From: Karsten Behrmann
- Re: Pluggable Disk Scheduler Project
- From: Ulf Lilleengen
- Re: Pluggable Disk Scheduler Project
- From: Fabio Checconi
- Re: Pluggable Disk Scheduler Project
- From: Ulf Lilleengen
- Pluggable Disk Scheduler Project
- Prev by Date: Re: Pluggable Disk Scheduler Project
- Next by Date: Re: Interrupt/speed problems with 6.2 NFS server
- Previous by thread: Re: Pluggable Disk Scheduler Project
- Next by thread: Re: Pluggable Disk Scheduler Project
- Index(es):
Relevant Pages
|
|