linux-kernel - Re: volanoMark regression with kernel 2.6.26-rc1

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: <1210584047.6524.12.camel@lappy.programming.kicks-ass.net>
Date:	Mon, 12 May 2008 11:20:47 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Mike Galbraith <efault@....de>
Cc:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	vatsa@...ux.vnet.ibm.com, Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Aneesh Kumar KV <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: volanoMark regression with kernel 2.6.26-rc1

On Mon, 2008-05-12 at 11:04 +0200, Mike Galbraith wrote:
> On Mon, 2008-05-12 at 13:02 +0800, Zhang, Yanmin wrote:
> 
> > A quick update:
> > With 2.6.26-rc2 (CONFIG_USER_SCHED=y), volanoMark result on my 8-core stoakley
> > is about 10% worse than the one of 2.6.26-rc1.
> 
> Here (Q6600), 2.6.26-rc2 CONFIG_USER_SCHED=y regression culprit for
> volanomark is the same one identified for mysql+oltp.
> 
> (i have yet to figure out where the buglet lies, but there is definitely
> one in there somewhere)
> 
> 2.6.25.3-smp (baseline, no group scheduling)
> test-1.log:Average throughput = 102412 messages per second
> test-2.log:Average throughput = 99636 messages per second
> test-3.log:Average throughput = 99373 messages per second
> 
> CONFIG_CGROUPS=n
> CONFIG_USER_SCHED=y
> 
> 2.6.26-rc2 - 18d95a2832c1392a2d63227a7a6d433cb9f2037e
> test-1.log:Average throughput = 102341 messages per second
> test-2.log:Average throughput = 101710 messages per second
> test-3.log:Average throughput = 100572 messages per second
> 
> 
> 2.6.26-rc2 + 18d95a2832c1392a2d63227a7a6d433cb9f2037e
> test-1.log:Average throughput = 79506 messages per second
> test-2.log:Average throughput = 78168 messages per second
> test-3.log:Average throughput = 78200 messages per second

> CONFIG_CGROUPS=y
> CONFIG_CGROUP_SCHED=y
> 
> 2.6.26-rc2 - 18d95a2832c1392a2d63227a7a6d433cb9f2037e
> test-1.log:Average throughput = 103026 messages per second
> test-2.log:Average throughput = 101152 messages per second
> test-3.log:Average throughput = 102616 messages per second
> 
> 2.6.26-rc2 + 18d95a2832c1392a2d63227a7a6d433cb9f2037e
> test-1.log:Average throughput = 104174 messages per second
> test-2.log:Average throughput = 101390 messages per second
> test-3.log:Average throughput = 101212 messages per second
> 
> (but there are no task groups set up...)

Yeah, I expect that when you create some groups and move everything down
1 level you'll get into the same problems as with user grouping.

The thing seems to be that rq weights shrink to < 1 task level in these
situations - because its spreading 1 tasks (well group) worth of load
over the various CPUs.

We're going through the load balance code atm to find out where the
small load numbers would affect decisions.

It looks like things like find_busiest_group() just think everything is
peachy when the imbalance is < 1 task - which with all this grouping
stuff is not necessarily true.

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