elevator priorities vs. full request queues

[Werner Almesberger <wa@almesberger.net>]

Another issue regarding priorities: let's suppose we have "high"
and "low" priority requests. Those priorities are indicated by
some means, and do not depend on CPU scheduler priorities. Let's
say that the elevator always handles high priority requests
first, unless barriers dictate it to do otherwise.

So far so good. Next, let's suppose that the request queue is
filling up. Now all the processes doing IO will compete for
request slots, and the outcome of this competition is
determined by the CPU scheduler - which is blissfully unaware
of those request priorities.

Has anybody thought of a solution for this problem ?

I can think of a few possible approaches, but they're all
relatively intrusive or plain ugly. A few of them:

 1) temporarily raise the CPU priority of processes waiting
    for request queue slots
 2) implement some priority scheme in ll_rw_blk.c
 3) give elv_may_queue more information about what the request
    will look like, so that it can decide to accept "high"
    priority requests even if the queue is officially full
 4) allow elv_add_request to refuse requests, e.g. to keep
    some reserve for "high" priority requests

1) and 2) would have the advantage that they also work if
requests are delayed due to a lack of memory. However, in this
case, all bets are off anyway, so I wouldn't worry too much
about it.

3) and 4) have the nice property of keeping all the priority
logic entirely in the elevator. For 4), one would also have to
force an interface change (besides giving elv_add_request a
return value), to make sure there are no enqueuers left in the
kernel or elsewhere which don't know that elv_add_request may
now fail.

Opinions ?

- Werner

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