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]

Message-ID: <4629BE29.6010306@bigpond.net.au>
Date:	Sat, 21 Apr 2007 17:32:57 +1000
From:	Peter Williams <pwil3058@...pond.net.au>
To:	William Lee Irwin III <wli@...omorphy.com>,
	Ingo Molnar <mingo@...e.hu>
CC:	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:
> William Lee Irwin III wrote:
>> William Lee Irwin III wrote:
>> On Sat, Apr 21, 2007 at 10:23:07AM +1000, Peter Williams wrote:
>>> If some form of precise timer was used (instead) to trigger 
>>> pre-emption then, where there is more than one task with the same 
>>> expected "on CPU" time, only the last would get any CPU (and that's 
>>> only the case if some infinite loop doesn't get created).
>>
>> I think you can check for this and adjust their on-cpu times in various
>> ways and choose what order to run them in. I think it'd end up something
>> of a missed deadline policy.
> 
> Arguably the latest one should go first as its estimate is more likely 
> to be correct being based on more recent info i.e. the other's estimates 
> would be based on less runnable tasks and be optimistic. This would 
> involve pushing them down the queue and pushing items already on the 
> queue downwards is likely to be expensive.  Which is why I prefer the 
> less elegant solution of the periodical interrupt.
> 
> Of course, one solution might be to just add the adjustment to the key 
> time on all tasks on the queue?

I retract this suggestion as it's a very bad idea.  It introduces the 
possibility of starvation via the poor sods at the bottom of the queue 
having their "on CPU" forever postponed and we all know that even the 
smallest possibility of starvation will eventually cause problems.

I think there should be a rule: Once a task is on the queue its "on CPU" 
time is immutable.

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/