Bug 497181

=Comment: #0=================================================
Emily J. Ratliff <ratliff.com> - 
1. Feature Overview:
Feature Id:	[201925]
a. Name of Feature:	Nominate power efficient idle loadbalancer
b. Feature Description
This patchset improves the idle-load balancer nomination logic, by  taking into consideration the
system topology.
 
An idle-load balancer is an idle-cpu which does not turn off it's sched_ticks and performs
load-balancing on behalf of the other idle CPUs. Currently, this idle load balancer is nominated as
the first_cpu (nohz.cpu_mask)

2. Feature Details:
Sponsor:	Linux Systems Tech
Architectures:
x86_64
ppc64
s390x

Arch Specificity: Purely Common Code
Affects Core Kernel: Yes
Affects Kernel Modules: Yes
Delivery Mechanism: Direct from community
Category:	Kernel
Request Type:	Kernel - Enhancement from Upstream
d. Upstream Acceptance:	Pending
Sponsor Priority	1
f. Severity: High
IBM Confidential:	no
Code Contribution:	IBM code
g. Component Version Target:	Patch and discussions: (Version 2)
 http://lkml.org/lkml/2009/4/2/246
 
 Patch series in Ingo's sched-tip on 14 April 09.

3. Business Case
The drawback of the current method is that the CPU numbering in the cores/packages need not
necessarily be sequential.  Now, the other power-savings settings such as the
sched_mc/smt_power_savings and the power-aware IRQ balancer try to balance tasks/IRQs by taking the
system topology into consideration, with the intention of keeping as many 'power-domains'
(cores/packages) in the low-power state.
 
The current idle-load-balancer nomination does not necessarily align towards this policy. For eg, we
could be having tasks and interrupts largely running on the first package with the intention of
keeping the second package idle.  Hence, CPU 0 may be busy. The first_cpu in the nohz.cpu_mask could
be CPU1, which in-turn becomes nominated as the idle-load balancer. CPU1 could be from the 2nd
package, would in turn prevent the 2nd package from going into a deeper sleep state.
 
Instead the role of the idle-load balancer could have been assumed by an idle CPU from the first
package, thereby helping the second package go completely idle.

4. Primary contact at Red Hat: 
John Jarvis
jjarvis

5. Primary contacts at Partner:
Project Management Contact:
Stephanie Glass, sglass.com, 512-838-9284

Technical contact(s):

Vaidyanathan Srinivasan, svaidyan.com

IBM Manager:
Jeffrey Heroux, heroux.com