linux-kernel - Re: [PATCH] mechanism to disable built in cpu frequency drivers/governors. (v1)

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: <4F605B030200007800078327@nat28.tlf.novell.com>
Date:	Wed, 14 Mar 2012 07:46:59 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>
Cc:	<davej@...hat.com>, <cpufreq@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mechanism to disable built in cpu frequency
 drivers/governors. (v1)

>>> On 14.03.12 at 00:18, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> The purpose of these patches is two-fold:
>  1) Remove weird performance issues encountered in the field where the
>     Linux kernel cpufreq scaling drivers would change the P-states while the
>     Xen hypervisor would do the same.
>  2) Provide a runtime knob from within the kernel to disable the cpu 
> frequency
>     API (akin to the behavior of "#CONFIG_CPU_CPUFREQ is not set").

Acked-by: Jan Beulich <jbeulich@...e.com>

(Albeit I'd recommend using 'bool' for the variable and function return
types in the first patch.)

> The patches are based on the mechanism that Len Brown came up for the 
> cpuidle
> drivers - where there is a disable_cpuidle() call. His patches also provided
> a module parameter - but I wasn't sure whether that is something you would 
> want.
> (for reference, Len's patch is d91ee5863b71e8c90eaf6035bff3078a85e2e7b5)
> 
> The other way of disabling the cpufreq scaling drivers from being invoked
> is by thwarting the cpufreq drivers from loading by influencing their 
> startup
> checks.  For powernow-k8 that is easy - disallow the RDMSR (and that is 
> currently
> happening). For acpi-cpufreq I am not sure what could be done - the calls it
> makes are to the ACPI libraries which we need for other uses.
> 
> Another solution I thought off was to provide a cpufreq governor that would
> be a nop, and hence end up not calling the cpufreq scaling drivers. But that
> just seems heavy-handed and I am not sure how the decision of when to load it
> (and set it) would be done.
> 
>  arch/x86/xen/setup.c      |    1 +
>  drivers/cpufreq/cpufreq.c |   24 ++++++++++++++++++++++++
>  include/linux/cpufreq.h   |    2 ++
>  3 files changed, 27 insertions(+), 0 deletions(-)



--
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/