lkml.org 
[lkml]   [2013]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/4] CPUFreq: Implement per policy instances of governors
From
On 4 February 2013 19:39, Borislav Petkov <bp@alien8.de> wrote:
> On Mon, Feb 04, 2013 at 07:28:16PM +0530, Viresh Kumar wrote:
>> All files which are directly present in cpu/cpu*/cpufreq/ folder. I am
>> not talking about governor tunables but policy tunables. Things like
>> scaling_[min]max_freq are policy tunables.
>
> No, on x86 those are the P-states frequencies. They're defined by the
> hardware.

A question we need to answer: What is "policy"?

For me, "policy" is the hardware policy for a group of cpus, defined by the
hardware. We call them P-states. But these are strictly per policy (i.e. per
cpu group sharing clock line).

So, if we have two packages with two cpus each, we will have two copies
of these P-states and every other file/directory in cpu/cpu*/cpufreq.
One common copy would be shared between cpu/cpu[0-1]/cpufreq
directory and other one between cpu/cpu[2-3]/cpufreq.

>> Policies don't have a name associated with them and so
>> cpu/cpufreq/policies doesn't make any sense. Rather one policy is
>> related to multiple cpus and its tunables are linked in all the cpus
>> that belong to it, like scaling_[min]max_freq.
>
> Then do the following:
>
> cpu/cpufreq/policies/
> |-> policy0
> |-> min_freq
> |-> max_freq
> |-> affected_cpus
> ...

We correlate things with cpus rather than policies and so the current directory
structure of cpu/cpu*/cpufreq/*** is the best suited ones.

> or whatever needs to be a flexible interface for multi-policy cpufreq
> support.

The multi policy part is already well implemented, we are talking about governor
per policy here.

> Remember: once you do those, they're more or less cast in stone so take
> your time and do the design right, do not hurry those.

Yes, and that's why cpu/cpu*/cpufreq/ondemand/*** suits the best, with exactly
the same logic that went for P-states or cpufreq-stats.

>> But then we will get governors tunables in cpu/cpu*/cpufreq/ instead
>> of cpu/cpufreq/ . Will that not break userspace for other systems?
>
> What's wrong with having both? The cpu/cpufreq/ governor will set the
> system-wide governor and the cpu/cpu*/cpufreq/ will add the different
> policies.

Hmm.. confused..
Consider two systems:
- A dual core system, with cores sharing clocks.
- A dual cluster system (dual core per cluster), with separate clocks
per cluster.

Where will you keep governor directories for both of these configurations?

We need to select only one... cpu/cpufreq doesn't suit the second case at all
as we need to use ondemand governor for both the clusters but with separate
tunables. And so a single cpu/cpufreq/ondemand directory wouldn't solve the
issue.

--
viresh


\
 
 \ /
  Last update: 2013-02-04 16:04    [W:0.115 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site