linux-kernel - Re: [RFC PATCH v1 0/3] Saving power by cpu evacuation using sched

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]

Message-Id: <1240907618.7620.86.camel@twins>
Date:	Tue, 28 Apr 2009 10:33:38 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	svaidy@...ux.vnet.ibm.com
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Suresh B Siddha <suresh.b.siddha@...el.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Vatsa <vatsa@...ux.vnet.ibm.com>,
	Gautham R Shenoy <ego@...ibm.com>,
	Andi Kleen <andi@...stfloor.org>,
	Gregory Haskins <gregory.haskins@...il.com>,
	Mike Galbraith <efault@....de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arun Bharadwaj <arun@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH v1 0/3] Saving power by cpu evacuation using
 sched_mc=n

On Mon, 2009-04-27 at 19:50 +0530, Vaidyanathan Srinivasan wrote:
> * Peter Zijlstra <a.p.zijlstra@...llo.nl> [2009-04-27 12:09:14]:

> > The whole thing seems to be targeted at thermal management, not power
> > saving. Therefore using the power saving stuff is backwards.
> 
> The framework is useful for power savings and thermal management.
> Actually we can generalise this a framework to throttle cores.

To what purpose?

> Power savings need only core evacuation, kernel can decide the most
> optimum cores to evacuate for best power savings.  While in thermal
> management we will additional need a 'vector' parameter to direct the
> load to different parts of the system and level the heat generated.

Power saving should not generate idle, it should just accumulate idle in
the most favourable way.

Thermal management must generate idle to avoid hardware breakdown etc.
Does it really need more than a single max_thermal_capacity knob? That
is, does it really matter which die in the machine generates the heat?

If so, why?
 
> > Provide a knob that provides max_thermal_capacity, and schedule
> > accordingly.
> 
> Yes, we can pick a generic name and use this as a function of total
> system capacity to indicate number of cores to evacuate.

No, it should be in a thermal unit, not nr of cores.

> > FWIW I utterly hate these force idle things because they cause the
> > scheduler to become non-work conserving, but I have to concede that
> > software will likely be more suited to handle the thermal overload issue
> > than hardware will ever be -- so for that use case I'm willing to go
> > along.
> 
> Yes, I agree with your opinion.  However if we can come up with
> a clean framework to take cores out of scheduler's view, then the work
> conserving nature of the scheduler can be preserved on the sub-set of
> cores.  Inserting idle states is more intrusive than leaving out full
> cores.

Not really, when you consider the machine (or load-balance domain)
taking out a few cores it still non-work preserving as you take away
capacity.

I'm against taking out capacity for anything other than thermal
management -- full stop.

> > Also, the user interface should be that single thermal capacity knob,
> > more fine grained control is undesired.
> 
> For power savings, a single evacuation knob will do.  While for
> thermal we will need additional parameters to choose the right cores
> to evacuate.  Some sort of directional/vector parameter.

Why? are machines that non-uniform in cooling capacity that it really
matters which core generates the heat? Sounds like badly designed
hardware to me.

I would expect it to only be the total head generated/power taken from
the rack unit.

> > Also, before you continue, expand on the interaction with realtime
> > processes.
> 
> Sure.  We will run into complications with respect to realtime
> scheduling.  You had earlier pointed out a need for variable cpu power
> to achieve fairness for non-realtime tasks in the presence of realtime
> tasks.  We should re-visit that idea.

There is that, another point is load generated by SCHED_OTHER tasks
pushing the machine in thermal overload should not shut down the
capacity needed for the real-time tasks.


--
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/