Re: [PATCH] Priorities in Anticipatory I/O scheduler

[Aaron Carroll]

Naveen Gupta wrote:
> 2008/10/28 Aaron Carroll <aaronc@xxxxxxxxxxxxxxxxxx>:
>> Naveen Gupta wrote:
>>> As I said earlier the organization of the AS levels is flat, so we
>>> could use any class (RT, BE, LATENCY) and fold the remaining ones. The
>>> other way which you would probably like is to increase number of
>>> levels and map different classes so that they are not folded.
>> As I said in my reply to the initial posting of this, I think there are
>> only two sensible ways of handling this:
>>
>>  1) Maintain the full number of I/O priorities (1 IDLE, 8 BE, 8 RT);
> 
> But then we are assuming that we are providing different quality of
> service according to classes.

Right.  The ideal solution is a scheduler-independent definition of
RT (Jens?) which you can apply here.  However, it seems to me that you
want to basically ignore RT and IDLE. If you're going to do that, at
least implement sane alternate behaviour.

This solution applies the the principle of least surprise; RT requests
always have higher priority than BE requests, and within the class,
higher level means higher priority.  In your implementation, BE 0 == RT x
and IDLE == BE 7.  This is surprising behaviour.

>>  2) Collapse the levels and only deal with the classes;
> 
> I am not sure if this is meaningful. When all we have is different
> levels of BE, it wouldn't make sense to call them different classes.

It's not meaningful as it stands.  This difference here is that you
at least maintain the ordering of the classes with respect to priority.


           -- Aaron


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/