lkml.org 
[lkml]   [2009]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[RFC PATCH v1 0/3] Saving power by cpu evacuation using sched_mc=n
Date
Hi,

The sched_mc_powersavings tunable can be set to {0,1,2} to enable
aggressive task consolidation to less number of cpu packages and save
power. Under certain conditions, sched_mc=2 may provide better
performance in a underutilised system by keeping the group of tasks on
a single cpu package facilitating cache sharing and reduced off-chip
traffic.
Extending this concept further, the following patch series tries to
implement sched_mc={3,4,5} where CPUs/cores are forced to be idle and
thereby save power at the cost of performance. Some of the cpu
packages in the system are overloaded with tasks while other packages
can have free cpus. This patch is a hack to discuss the idea and
requirements.
Objective:
----------
* Framework to evacuate tasks from cpus in order to force the cpu
cores to stay at idle

* Interrupts can be moved using user space irqbalancer daemons, while
timer migration framework is being discussed:
http://lkml.org/lkml/2009/4/16/45

* Forcefully idling cpu cores in a system will reduce the power
consumption of the system and also cool cpu packages for thermal
management

Requirements:
------------
* Fast response time and low OS overhead to moved tasks away from
selected cpu packages. CPU hotplug is too heavyweight for this
purpose

Use cases:
---------
* Enabling the right number of cpus to run the given workload can
provide good power vs performance tradeoffs.

* Ability to throttle the number of cores uses in the system along
with other power saving controls like cpufreq governors can enable
the system to operate at a more power efficient operating point and
still meet the design objectives.

* Facilitate thermal management by evacuating cores from hot cpu packages

Alternatives:
-------------
* CPU hotplug: Heavy weight and slow. Setting up and tear down of
data structures involved. May need new fast or light weight
notifications

* CPUSets: Exclusive CPU sets and partitioned sched domains involve
rebuilding sched domains and relatively heavy weight for the purpose

The following patch is against 2.6.30-rc3 and will work only in
an under utilised system (Tasks <= number of cores).

Test results for ebizzy 8 threads at various sched_mc settings has been
summarised with relative values below. The test platform is dual socket
quad core x86 system (pre-Nehalem).

--------------------------------------------------------
sched_mc No Cores Performance AvgPower
used Records/sec (Watts)
--------------------------------------------------------
0 8 1.00x 1.00y
1 8 1.02x 1.01y
2 8 0.83x 1.01y
3 7 0.86x 0.97y
4 6 0.76x 0.92y
5 4 0.72x 0.82y
--------------------------------------------------------
There were wide run variation with ebizzy. The purpose of the above
data is to justify use of core evacuation for power vs performance
trade-offs.

ToDo:
-----
* Make the core evacuation predictable under different system load
conditions and workload characteristics
* Enhance framework to control which packages/cores will be
evacuated, this is needed for thermal management

I can experiment with different benchmarks/platforms and post results
while the framework is being discussed.

Please let me know you comments and suggestions.

Thanks,
Vaidy

---
Vaidyanathan Srinivasan (3):
sched: loadbalancer hacks for forced packing of tasks
sched: threshold helper functions
sched: add more levels of sched_mc


include/linux/sched.h | 4 ++++
kernel/sched.c | 35 ++++++++++++++++++++++++++++++++++-
2 files changed, 38 insertions(+), 1 deletions(-)
--


\
 
 \ /
  Last update: 2009-04-26 22:51    [W:0.090 / U:0.248 seconds]
©2003-2014 Jasper Spaans. Advertise on this site