Re: elevator priorities vs. full request queues

[Werner Almesberger <wa@almesberger.net>]

Jens Axboe wrote:
> Well yes, different parties have worked on io priorities in the past.
> Request allocation is a important part of that.

I only found your "cfq + io priorities" posting from November
2003. Are there any others that are publicly available ?

> #4 doesn't work for various reasons, the obvious being that the request
> is already allocated at this point.

The idea would be to refuse/delay low-priority requests before
reaching the queue limit. But yes, having a possibly large
number of allocated but not enqueuable requests sit around,
or being forced to discard requests after building them, may
not be so great.

> CFQ with priorities used a combination of 2+3. It seems you haven't
> looked any of this up, maybe that would be a good starting point.

I had to have a second look :-) I didn't quite realize that
your changes actually solved that. Nice and simple. Are there
any newer versions of it ? What are your plans for IO priorities
anyway ?

> CFQ used per-process (-group) priorities,

In my case, they're per open file or per memory page. The latter
works as follows: pages are explicitly prefetched at the
application's declared read rate. When doing this, the prefetcher
sets the page's priority, which the elevator retrieves. Sound
complicated but actually doesn't cause all that much overhead. As
a welcome side-effect, prefetching also limits the high-priority
IO activity an application can generate.

> A bio has room for priority info, so you could also pass it in
> from submit_bio() -> __make_request() -> get_request() -> may_queue().

Hmm yes, that's the large set of little changes I was hoping to
avoid. But I guess there's no way around this.

Thanks,
- Werner

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