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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Oct 2008 13:05:12 +1100
From:	Aaron Carroll <aaronc@...ato.unsw.edu.au>
To:	Naveen Gupta <ngupta@...gle.com>
CC:	linux-kernel@...r.kernel.org, jens.axboe@...cle.com,
	akpm@...ux-foundation.org, s-uchida@...jp.nec.com,
	david@...morbit.com
Subject: Re: [PATCH] Priorities in Anticipatory I/O scheduler

Naveen Gupta wrote:
> 2008/10/28 Aaron Carroll <aaronc@...ato.unsw.edu.au>:
>> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/