Re: elevator priorities vs. full request queues

[Werner Almesberger <wa@almesberger.net>]

Jens Axboe wrote:
> Don't like that approach. I don't see why you'd need more than the
> priority passed in anyways?

I don't need more, but my priorities originally sit on open
files, and may then propagate to pages, from where the
elevator picks them up. Your bio-centric approach breaks
this.

Well, maybe that's just an opportinity to do something
better :-) How do you think the priorities should get into
the bio, i.e. who calls bio_set_prio ?

The properties I'm looking for are:

 - priorities are per open file (whether a process is allowed
   to raise the priority of a file may depend on a number of
   factors, so this would be compatible with your "io
   priorities", except that the process has to ask explicitly
   before an open file gets a non-default priority)

 - the kernel can grant priorities either a) for the entire
   file, or b) depending on whether the data rate is below a
   certain limit. (The latter if for really high priorities.
   I'm combining this with a special readahead mechanism, so 
   I'm simply boosting the priority of pages that will be
   read ahead. The read ahead is done by yet another kernel
   thread.)

b) is actually the easy part, because there all action is
initiated by my code. a) is harder, because there, the open
file just has a priority that somehow needs to propagate to
the bio.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/