linux-kernel - Re: [PATCH 10/15] sched: Check for sched_mn_power

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Aug 2009 10:00:20 +0200
From:	Andreas Herrmann <andreas.herrmann3@....com>
To:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
CC:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
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@...radead.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/