linux-kernel - Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs

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: <20160204113102.GA17371@in.ibm.com>
Date:	Thu, 4 Feb 2016 17:01:02 +0530
From:	Gautham R Shenoy <ego@...ux.vnet.ibm.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	ego@...ux.vnet.ibm.com, "Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Juri Lelli <juri.lelli@....com>,
	Steve Muckle <steve.muckle@...aro.org>,
	Saravana Kannan <skannan@...eaurora.org>
Subject: Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data
 pointer

Hello Viresh,

On Thu, Feb 04, 2016 at 01:55:38PM +0530, Viresh Kumar wrote:
> On 04-02-16, 13:44, Gautham R Shenoy wrote:
> > In a a two policy system, to run ondemand on one and conservative on the other,
> >  won't the driver have CPUFREQ_HAVE_GOVERNOR_PER_POLICY set?  
> 
> No.
> 
> CPUFREQ_HAVE_GOVERNOR_PER_POLICY is not about the facility of using
> separate governor-type for each policy, that is always available to
> the user.
> 
> CPUFREQ_HAVE_GOVERNOR_PER_POLICY was initially added for platforms
> with different type of CPUs on the same chip, though others can
> benefit from it as well.
> 
> For example, on a 4 core ARM big LITTLE platform, we will have:
> - 2 A7 (low performance/low power)
> - 2 A15 (high performance/high power)
> 
> The A7's share a policy and A15's share another one.
> 
> Without CPUFREQ_HAVE_GOVERNOR_PER_POLICY, if ondemand is selected for
> both the policies, the we used to get a single directory (and a set of
> tunables) at /sys/devices/system/cpu/cpufreq/ondemand/ .
> 
> That used to force us to use same tunables, like sampling rate, etc
> for both the policies.
> 
> But because the CPUs were so different, we really wanted independent
> control.
> 
> So, we designed CPUFREQ_HAVE_GOVERNOR_PER_POLICY, so that in such
> cases, each policy will have a set of tunables for the same governor
> type.
> 
> Hope that makes it clear.

Yes it does! Thank you for the explanation.

So, the CPUFREQ_HAVE_GOVERNOR_PER_POLICY is really
CPUFREQ_HAVE_GOVERNOR_TUNERS_PER_POLICY. Can we change the name to
reflect the intent?

> 
> If the below questionnaire is still valid, please let me know :)

No, it is no longer valid!
> 
> viresh

--
Thanks and Regards
gautham.