On Thu, Jun 20, 2002 at 05:58:50PM -0400, John Franklin wrote:
> On Thu, Jun 20, 2002 at 11:24:33PM +0200, Manuel Bouyer 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).
> 
> Yes, I can see this to prevent starvation.  Would an on-demand queue be
> needed for real-time operations?  Actually, it could be added in later
> when harder real-time support is added to the kernel.

Yes, once the priority are there, this should easy to add.

> 
> > > 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 preventing this in my proposal. The priority put on parititons
> > could just be a hint among others for the kernel when choosing the queue.
> 
> While hints keep the kernel in control (a Good Thing), would the hints
> also guarantee write A has a higher priority than B and therefore A would 
> be written out first?  I'm thinking about softdeps here, in particular.

This is not priority, these are what write barrier are for. And note that
for now nothing use the buf write barrier, the filesystems implement their
own barrier, by waiting for I/O to be done before queuing new ones.
disksort(), and later tagged queuing will reorder I/O requests anyway
in the current implementation.

> 
> > > If you want a particular mount to have a higher priority, a mount flag 
> > > would instruct the file system 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.
> 
> Fair enough.  That would allow adjusted priority to databases or news
> servers that directly manage a partition.  I'd like to see it as a mount
> flag as well, though, so you can test a priority without having to rewrite 
> the disklabel, and change a mounted file system with a mount -u.

You can change only the in-core disklabel :)

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