This is a discussion on Re: Pluggable Disk Scheduler Project - FreeBSD ; > From: Ulf Lilleengen > 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 ...
> From: Ulf Lilleengen
> 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.
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?
> Also, I got my test-box up again today, and will be trying your patch as soon
> as I've upgraded it to CURRENT Fabio.
Thank you very much! Please consider that my primary concern with
the patch was its interface, the algorithm is just an example (it
should give an idea of the performance loss due to the mechanism
overhead with async requests, and some improvement on greedy sync
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"