linux-kernel - RE: [PATCH 0/4] CPUFreq: Implement per policy instances of governors

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, 5 Feb 2013 18:38:07 +0000
From:	Charles Garcia-Tobin <Charles.Garcia-Tobin@....com>
To:	Borislav Petkov <bp@...en8.de>
CC:	Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-dev@...ts.linaro.org" <linaro-dev@...ts.linaro.org>,
	Robin Randhawa <Robin.Randhawa@....com>,
	Steve Bannister <Steve.Bannister@....com>,
	Liviu Dudau <Liviu.Dudau@....com>
Subject: RE: [PATCH 0/4] CPUFreq: Implement per policy instances of governors

>
> On Tue, Feb 05, 2013 at 11:29:04AM +0000, Charles Garcia-Tobin wrote:
> > Actually shooting myself in the foot here, Krait is not such a great
> > example because although you can use difference between frequencies
> > you are less likely to use different tunables (not inconceivable
> > but unlikely). The best examples systems are multi cluster and
> > hereterogeneous systems, like the recently announced Samsung Exynos 5
> > octa http://en.wikipedia.org/wiki/Exynos_(system_on_chip). We will see
> > more systems like this appearing, sporting low power cores combined
> > with high performance ones, all running at the same time. I appreciate
> > this is all very new, but more will come, and the requirement to have
> > different tunables per cluster is very real. In ARM on our own multi
> > cluster test chip, using an experimental version of this approach, we
> > have seen good improvements in power consumption without compromising
> > performance.
>
> Ok, thanks for giving this insight, this is useful.
>
> Question: do you need the granularity of that control to be per cpu
> (with that I mean what linux understands under "cpu," i.e. logical or
> physical core) or does one governor suffice per a set of cores, or as
> you call it, a cluster?
>

Later. Whatever you'd like to call it, but essentially a set of cpus, as linux understands them, that are logically related by the fact that you'd like to be able to use the same tuning policy and same governor across all of them.

Cheers

Charles

(apologies again for annoying addendums to follow)


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.