Messages in this thread | | | Date | Mon, 4 Feb 2013 15:09:08 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors |
| |
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.
> 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 ...
or whatever needs to be a flexible interface for multi-policy cpufreq support.
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.
> Don't have examples of these, but there can be few. Over that it is a > must for multicluster systems as clusters normally have separate clock > control.
Yeah, nice try. We only support real hardware in the kernel, not what could there be.
> 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.
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine. --
| |