linux-kernel - Re: [patch] CFS (Completely Fair Scheduler), v2

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] [day] [month] [year] [list]

Message-ID: <46266E5F.4060205@bigpond.net.au>
Date:	Thu, 19 Apr 2007 05:15:43 +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>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>
Subject: Re: [patch] CFS (Completely Fair Scheduler), v2

Peter Williams wrote:
> William Lee Irwin III wrote:
>> Ingo Molnar wrote:
>>>> this is the second release of the CFS (Completely Fair Scheduler) 
>>>> patchset, against v2.6.21-rc7:
>>>>    http://redhat.com/~mingo/cfs-scheduler/sched-cfs-v2.patch
>>>> i'd like to thank everyone for the tremendous amount of feedback and 
>>>> testing the v1 patch got - i could hardly keep up with just reading 
>>>> the mails! Some of the stuff people addressed i couldnt implement 
>>>> yet, i mostly concentrated on bugs, regressions and debuggability.
>>
>> On Tue, Apr 17, 2007 at 04:46:57PM +1000, Peter Williams wrote:
>>> Have you considered using rq->raw_weighted_load instead of 
>>> rq->nr_running in calculating fair_clock?  This would take the nice 
>>> value (or RT priority) of the other tasks into account when 
>>> determining what's fair.
>>
>> I suspect you mean (curr->load_weight*delta_exec)/rq->raw_weighted_load
>> in update_curr().
> 
> Or something like that, yes. :-)

Actually, this formula can't be used for the migration thread itself as 
its load_weight isn't an accurate reflection of its static priority. 
But as the migration thread is a real time task this probably isn't an 
issue, right?

If this assumption is correct (i.e. curr is never a real time task) then 
my earlier caveat re division by zero being possible is invalid because 
the migration task will never be the only task on the runqueue when this 
code is called.

I'm also assuming here that (because of its name) curr is already on the 
runqueue when this code is called.  If it isn't the divisor in the above 
expression should be (rq->raw_weighted_load + curr->load_weight).  This 
would also preclude the possibility of divide by zero.

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/