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