Re: volanoMark regression with kernel 2.6.26-rc1

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

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.