linux-kernel - Re: unpredictability in scheduler test results -- still present

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, 24 Sep 2008 09:19:32 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: unpredictability in scheduler test results -- still present

Chris Friesen wrote:

> I'm using the test config listed at the bottom.  It's pretty 
> straightforward.

> On the second run, the task distribution is almost perfect, but the 
> system was only using one of the two cpus as seen by the difference 
> between actual and expected cpu time.
> 
> Warning, actual cpu time different than expected. actual: 10033.011108, 
> expected: 20000.000000
> group       actual(%)     expected(%)  avg latency(ms) max_latency(ms)
>      1   0.24(30.59/29.88)    30.00      26/27             68/58
>      2       39.87            40.00       20                36
>      3   29.89(29.87/29.91)   30.00      28/27             47/60

This behaviour (that load balancing is messed up) is now almost 
continuous with both current tip/master and current Linus git.  On the 
first test after booting, it seems to work okay (although there are 
still issues with fairness).  On every subsequent test, fairness is good 
but it only uses one of the two cpus.

Also, building a kernel with "-j10" results in one cpu being mostly idle 
while the other one is 100% busy. It used to be both 100% busy--if I get 
time today I may try bisecting it.

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