[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140612165103.GD7594@gremlin.ru>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
