linux-kernel - some recent scheduler patches

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 2 Dec 2009 19:53:28 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>
Subject: some recent scheduler patches

Hi,

I'm just been looking through some of the recent scheduler patches
while bisecting something...

83f54960c11a14942ab00b54c51e91906b9d8235: sched: for_each_domain() vs RCU
I don't see what is the step that causes FAIL? sched-domains code is
using synchronize_sched(), so that part should be safe.

And b8a543ea5a5896830a9969bacfd047f9d15940b2... This changelog is not
correct to start with. The _idx stuff does not just shift the time
that balancing decisions are made, it damps balancing choices to be
more conservative if they might have been wrong over more than a single
instant sample.

And secondly there is no reason give for the change. Ditto for a lot of
other tuning changes really. Not that there was always exact reasons
for every single one of the defaults I found, but they a) always tried
to get reasonable performance with as conservative balancing as
possible (ie. so 2 different tunings with no distinguishable difference
then tuning that result in fewer task movements would be preferred).
And b) they were relatively well tested.

Are people really not reporting enough regressions against CFS that it
is time to just tweak things?

--
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/