Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Jun 2014 20:51:03 +0400
From: gremlin@...mlin.ru
To: owl-dev@...ts.openwall.com
Subject: Re: CPU power management

On 12-Jun-2014 18:44:43 +0400, Solar Designer wrote:

 > We need to support CPU power management not only for the
 > old-fashioned frequency scaling (which is arguably less
 > essential on servers than on laptops),

Power management is not only for saving electrical power, but
mostly to reduce the heat emission.

 > but also to have Intel's Turbo Boost enabled on many modern
 > servers (I saw this problem on servers with Xeon 5600 and
 > E5-2600 series CPUs).

I'd like to see the full hardware configuration of these servers...

 > In the latest Owl-current kernel build, I've enabled
 > CONFIG_CPU_FREQ* and related options like in RHEL5.

I recommend the following configuration:

CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
CONFIG_X86_PCC_CPUFREQ=y
CONFIG_X86_ACPI_CPUFREQ=y

 > Now on servers that previously ran without Turbo Boost
 > (oops!) it can be enabled with:
 > modprobe acpi-cpufreq

Never, I say, never compile it as a module! Almost half of ACPI
implementations are buggy and loading a module may cause the
mainboard to hang till a hardware reset or even power cycle.

Modules initialization sequence _does_ matter. Really.

 > but that's a hack. We could make this hack official by including
 > an improved version of it e.g. in /etc/init.d/turbo, so it could
 > be enabled or disabled with chkconfig.

2.6.32 kernels don't need that.

 > However, maybe it'd be better to include a CPU power management
 > package, like bigger distros do, which would also take advantage
 > of the CPUs' ability to scale the frequency down below the base
 > (non-turbo) frequency, thereby saving power. I guess the same
 > can be achieved by enabling this sort of governor via sysfs,
 > without a specialized tool for that, though.

That's the most safe way. And using the "conservative" governor by
default is really wise choice.

 > Fedora and RHEL7 have cpupower merged into the kernel source
 > package, which gets built into kernel-tools binary package:
 > [...]
 > I guess this is because cpupower has been merged with the Linux
 > kernel tree upstream
 > [...]
 > How should we approach this? Temporarily (while we still use
 > kernel versions that don't have cpupower in tree upstream)

So we don't need it for now...

 > and longer term.

... but we'll have to provide it in the future releases using newer
kernels.

 > Should we introduce cpupowerutils (like in RHEL6) into our package
 > tree for now, planning to drop it later (when we move to RHEL7'ish
 > kernels)?

Just a waste of time.


-- 
Alexey V. Vissarionov aka Gremlin from Kremlin <gremlin  gremlin  ru>
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ