linux-kernel - Re: High priority tasks break SMP balancer?

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: <20071116104801.GA4585@vmware.com>
Date:	Fri, 16 Nov 2007 02:48:01 -0800
From:	Micah Dowty <micah@...are.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Christoph Lameter <clameter@....com>,
	Kyle Moffett <mrmacman_g4@....com>,
	Cyrus Massoumi <cyrusm@....net>,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, Mike Galbraith <efault@....de>,
	Paul Menage <menage@...gle.com>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Peter Williams <pwil3058@...pond.net.au>
Subject: Re: High priority tasks break SMP balancer?

On Fri, Nov 16, 2007 at 07:07:00AM +0100, Ingo Molnar wrote:
> 
> * Micah Dowty <micah@...are.com> wrote:
> 
> > > I am a bit at a loss as to how this could relate to the patch. This 
> > > looks like a load balance logic issue that causes the load 
> > > calculation to go wrong?
> > 
> > My best guess is that this has something to do with the timing with 
> > which we sample the CPU's instantaneous load when calculating the load 
> > averages.. but I still understand only the basics of the scheduler and 
> > SMP balancer. All I really know for sure at this point regarding your 
> > patch is that git-bisect found it for me.
> 
> hm, your code uses timeouts for this, right? The CPU load average that 
> is used for SMP load balancing is sampled from the scheduler tick - and 
> has been sampled from the scheduler tick for eons. v2.6.23 defaulted to 
> a different method but v2.6.24 samples it from the tick again. So my 
> guess is, your testcode behave similarly on 2.6.22 too, correct?

Interesting.. here are the kernels I've tested so far, not including
the git-bisect run I did between 2.6.19 and 2.6.20:

2.6.17 -
2.6.19 -
2.6.19.7 -
2.6.20 +
2.6.21 +
2.6.22 -
2.6.23.1 +

Here a "-" means that the problem does not occur (my test program uses
100% of both CPUs) and a "+" means that the test program leaves one
CPU mostly idle.

Unless I've made a mistake, 2.6.22 seems like the outlier rather than
2.6.23. Is this inconsistent with the scheduler tick hypothesis?

Thanks,
--Micah
-
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/