On Thu, Jun 20, 2002 at 03:00:01PM -0700, Artem Belevich wrote:
> On Thu, Jun 20, 2002 at 11:24:33PM +0200, Manuel Bouyer <bouyer@antioche.eu.org> wrote:
> > On Thu, Jun 20, 2002 at 05:15:49PM -0400, John Franklin wrote:
> > > Why do we want to tie priorities to anything other than an abstraction of
> > > priorities?  That is, why not make an n-queue system in which queue 0 has
> > > the highest priority and must be cleared before anything on queue 1 can
> > > be serviced, then queue 2, dot dot dot, then queue n.  Then provide
> > 
> > No, there needs to be some limit for each queue, otherwise we can end up
> > with requests in lower priority queue never been serviced. I was thinking
> > at something more like proportional priorities (queue 1 gets serviced 1
> > time when queue 0 gets 2 times, or something like that).
> 
> I would think that priority reversal may be able to help there.  If a
> request wasn't completed within certain amount of time (different for
> each queue, I'd think) then move that request into a higher-priority
> queue. This way we can guarantee that even lowest-priority requests
> will eventually be served. 

Yes, this can be one solution. But I think these are implementation details :)

We also need to honnor I/O barriers, which is not trivial with multiple I/O
queue. I need to think about it more, but moving I/O from one queue to
another may be increase the complexity of I/O barriers implementation.
It's probably easier to no move the requests once they have been entered in a
queue, and implement the fairness in the algorithm which choose which
queue to run.
We also don't want to break disksort too much, which mean we'll probably want
to start several I/Os of a queue in a row.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--