linux-kernel - Re: [patch] CFS scheduler, v3

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:	Sat, 21 Apr 2007 18:07:56 +1000
From:	Peter Williams <pwil3058@...pond.net.au>
To:	Peter Williams <pwil3058@...pond.net.au>
CC:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Con Kolivas <kernel@...ivas.org>,
	Nick Piggin <npiggin@...e.de>, Mike Galbraith <efault@....de>,
	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>, caglar@...dus.org.tr,
	Willy Tarreau <w@....eu>, Gene Heskett <gene.heskett@...il.com>
Subject: Re: [patch] CFS scheduler, v3

Peter Williams wrote:
> Peter Williams wrote:
>> Ingo Molnar wrote:
>>> your suggestion concentrates on the following scenario: if a task 
>>> happens to schedule in an 'unlucky' way and happens to hit a busy 
>>> period while there are many idle periods. Unless i misunderstood your 
>>> suggestion, that is the main intention behind it, correct?
>>
>> You misunderstand (that's one of my other schedulers :-)).  This one's 
>> based on the premise that if everything happens as the task expects it 
>> will get the amount of CPU bandwidth (over this short period) that 
>> it's entitled to.  In reality, sometimes it will get more and 
>> sometimes less but on average it should get what it deserves. E.g. If 
>> you had two tasks with equal nice and both had demands of 90% of a CPU 
>> you'd expect them each to get about half of the CPU bandwidth.  Now 
>> suppose that one of them uses 5ms of CPU each time it got onto the CPU 
>> and the other uses 10ms.  If these two tasks just round robin with 
>> each other the likely outcome is that the one with the 10ms bursts 
>> will get twice as much CPU as the other but my proposed method should 
>> prevent and cause them to get roughly the same amount of CPU.  (I 
>> believe this was a scenario that caused problems with O(1) and 
>> required a fix at some stage?)

Another advantage of this mechanism is that, all else being equal, it 
will tend to run tasks that use short bursts of CPU ahead of those that 
use long bursts and this tends to reduce the overall time spent waiting 
for CPU by all tasks on the system which is good for throughput.  I.e. 
in general, a task that tends to use short bursts of CPU will make other 
tasks wait less time than will one that tends to use long bursts.

So this means that you were right and it is good in the scenario that 
you suggested even though that wasn't the motivation behind the design.

This means that this scheduler should be good for improving latency on 
servers that aren't fully loaded as well as providing good fairness and 
responsiveness when the system is fully loaded.  (Fingers crossed.)

Peter
-- 
Peter Williams                                   pwil3058@...pond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce
-
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/