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:	Mon, 4 Feb 2013 15:09:08 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, cpufreq@...r.kernel.org,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linaro-dev@...ts.linaro.org, robin.randhawa@....com,
	Steve.Bannister@....com, Liviu.Dudau@....com
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.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/