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

> kernel-based mechanisms for adding an I/O op to different level queues.

Yes, of course this is planned. That's not the difficult part :)

> 
> That way swap, when it is in trouble, can put a bunch of writes on queue 
> zero, but mundane housekeeping swap (like a process ending) is put on a
> lower-priority queue.

There's noting prevening this in my proposal. The priority put on parititons
could just be a hint among others for the kernel when choosing the queue.
> 
> Need I mention what a boon this would be for a journaled filesystem? :)
> Journal writes to queue x, other writes to queue x+1.
> 
> Of course, there has to be policy and security aspects here.  We don't 
> want everyone going for queue zero - it would defeat the purpose.  Queue
> zero would be for emergency kernel ops.  How to enforce it, other than 
> by code review?
> 
> If you want a particular mount to have a higher priority, a mount flag 
> would instruct the filesystem to bump its queue selection by one.

Not a mount flag, because not all partitions are mounted. I was thinking
about disklabel as the place for this information.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
--