[lkml]   [2008]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH v5 0/7] Tunable sched_mc_power_savings=n
* Pavel Machek <> [1970-01-01 01:13:43]:

> > Results:
> > --------
> >
> > Basic functionality of the code has not changed and the power vs
> > performance benefits for kernbench are similar to the ones posted
> > earlier.
> >
> > KERNBENCH Runs: make -j4 on a x86 8 core, dual socket quad core cpu
> > package system
> >
> > SchedMC Run Time Package Idle Energy Power
> > 0 81.28 52.43% 53.53% 1.00x J 1.00y W
> > 1 80.71 37.35% 68.91% 0.96x J 0.97y W
> > 2 76.05 23.81% 82.65% 0.92x J 0.98y W
> >
> > *** This is RFC code and not for inclusion ***
> Hmm, so it makes it compile faster _and_ it saves power? Why to keep
> it tunable at all if it is win-win? Or are there other benchmarks?

Hi Pavel,

The performance and power gain depends on the nature of the
application. If the processor cache is large enough, then
consolidation improves cache sharing and makes the system finish the
job faster. I would expect applications with larger cache foot print
and no data sharing may experience degradation in performance.

I am open to suggestion on any interesting workload that should be
tested. I have tested ebizzy and SPECjbb for power savings. I am
also looking forward to test reports from others having different
system topology and processor power saving features.

The idea behind the tunable is to have power saving as higher priority
in scheduling relative to performance. At higher sched_mc(2) settings
(aggressive power save mode), we should save power even if there is
a slight degradation in application performance. If we save power and
improve performance, then it is a best case scenario. However I would
expect certain workloads to sacrifice performance for the power

At sched_mc = 0 the scheduler would not optimise for power savings
and provide maximum performance for any application.

Kernel compile is a representative workload where my additional
optimisations for sched_mc=2 improves over the default sched_mc=1
implementation in the kernel.


 \ /
  Last update: 2008-12-14 21:09    [W:0.137 / U:18.060 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site