Re: Pluggable Disk Scheduler Project

On ons, okt 17, 2007 at 02:19:07 +0200, Fabio Checconi wrote:
From: Ulf Lilleengen <lulf@xxxxxxxxxxxx>
Date: Wed, Oct 17, 2007 01:07:15PM +0200

On tir, okt 16, 2007 at 04:10:37 +0200, Karsten Behrmann wrote:
Over to a more general view of it's architecture:

When I looked at this project for the first time, I was under the impression
that this would be best done in a GEOM class.

However, I think the approach that was taken in the Hybrid project is better

Ok. I think that such a solution requires a lot more effort on the
design and coding sides, as it requires the modification of the
drivers and can bring us problems with locking and with the queueing
assumptions that may vary on a per-driver basis.

I completely agree with the issue of converting device drivers, but at least
it will be an _optional_ possibility (Having different scheduler plugins
could make this possible). One does not necessary need to convert
the drivers.
Maybe I've not enough experience/knowledge of the driver subsystem,
but I would not remove the queueing that is done now by the drivers
(think of ata freezepoints,) but instead I'd like to try to grab
the requests before they get to the driver (e.g., in/before their
d_strategy call) and have some sort of pull mechanism when requests
complete (still don't have any (serious) idea on that, I fear that
the right place to do that, for locking issues and so on, can be
driver dependent.) Any ideas on that? Which drivers can be good
starting points to try to write down some code?

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.

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.

Also note (from the Hybrid page):
* we could not provide support for non work-conserving schedulers, due to a
couple of reasons:
1. the assumption, in some drivers, that bioq_disksort() will make
requests immediately available (so a subsequent bioq_first() will
not return NULL).
2. the fact that there is no bioq_lock()/bioq_unlock(), so the
scheduler does not have a safe way to generate requests for a given
queue.

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.

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.
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.

--
Ulf Lilleengen
_______________________________________________
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: [RFC] breakage in bsg
    ... get all requests with NULL ->rq_disk. ... That's pretty much by design since we need to allow bsg to be used on ... Since drivers have to ... that applies to all openers. ...
    (Linux-Kernel)
  • Broken PM semantics (WAS: PATCH: Shutdown IDE before powering off).
    ... it should use the same mecanism as the PM requests... ... drivers in favor of a "state" selector for PM. ... We should get rid of this assumption that we are passing a D-type ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: int 0x13 utility
    ... But is this a DOS or a BIOS level driver? ... But I don't know whether DOS can have it's own drivers to control HDs. ... Only read or write requests are handled. ...
    (comp.lang.asm.x86)
  • Re: [PATCH linux-2.6-block:master 10/10] blk: I/O barrier documentation
    ... +I/O barrier requests are used to guarantee ordering around the barrier ... +it sounds even more appealing now!), the reason you use I/O barriers ... +drivers have to are implementing its prepare_flush_fn and using one ...
    (Linux-Kernel)
  • Re: [PATCH linux-2.6-block:master 10/10] blk: I/O barrier documentation
    ... +I/O barrier requests are used to guarantee ordering around the barrier ... +it sounds even more appealing now!), the reason you use I/O barriers ... +drivers have to are implementing its prepare_flush_fn and using one ...
    (Linux-Kernel)