Messages in this thread | | | Date | Tue, 25 Aug 2009 10:00:20 +0200 | From | Andreas Herrmann <> | Subject | Re: [PATCH 10/15] sched: Check for sched_mn_power_savings when doing load balancing |
| |
On Mon, Aug 24, 2009 at 09:10:13PM +0530, Vaidyanathan Srinivasan wrote: > * Peter Zijlstra <peterz@infradead.org> [2009-08-24 17:03:40]: > > > On Thu, 2009-08-20 at 15:41 +0200, Andreas Herrmann wrote: > > > The patch adds support for POWERSAVINGS_BALANCE_BASIC for MN domain > > > level. Currently POWERSAVINGS_BALANCE_WAKEUP is not used for MN domain. > > > > > > (I have to admit that so far I don't have the correct understanding > > > what's the benefit of POWERSAVINGS_BALANCE_WAKEUP (when an deticated > > > wakeup CPU is used) in contrast to POWERSAVINGS_BALANCE_BASIC. I also > > > have not found an example that would demonstrate the difference > > > between those two powersaving levels.) > > > > blame svaidy for not writing enough comments ;-) > > I am here to explain ;) > > > iirc it moves tasks to sched_mv_preferred_wakeup_cpu instead of waking > > an idle cpu, this leaves idle cpus idle longer at the cost of creating > > overload on other cpus. > > Yes, as Peter said, the POWERSAVINGS_BALANCE_WAKEUP biases task > wakeups to sched_mc_preferred_wakeup_cpu which has been nominated from > previous load balance loops. > > Task wakeup biasing of sched_mc=2 works for most workloads like > kernbench and other sleeping tasks that come in and out of runqueue. > The default sched_mc=1 will work only for jobs running much longer > than the loadbalance interval or almost 100% CPU intensive job where
Ok, one of my tests was using 100% CPU intensive jobs and for those the sched_mc=1 or sched_mn=1 level was sufficient to show the effect of loadbalancing.
> the load balancer can take time to identify the load pattern and > initiate a task migrate.
> The wakeup biasing (sched_mc=2) will help move bursty jobs faster and > statistically pack them in single package and save power.
That means that wakeup biasing will also make sense for the MN domain.
Thanks,
Andreas
-- Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |