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.