Date: Sun, 29 Jun 2014 12:08:33 +0400 From: Solar Designer <solar@...nwall.com> To: owl-dev@...ts.openwall.com Subject: Re: CPU power management On Thu, Jun 12, 2014 at 08:51:03PM +0400, gremlin@...mlin.ru wrote: > On 12-Jun-2014 18:44:43 +0400, Solar Designer wrote: > > 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... It's multiple servers based on Xeon 5600 or E5-2600 series CPUs. There's nothing special about the rest of their hardware configs. The problem was confirmed to me by other people as well, and it's not unique to Owl: it is also seen with RHEL6'ish distros (CentOS 6 and Scientific Linux 6, so almost certainly with RHEL6 itself indeed). The problem is not seen with recent Ubuntu (due to newer kernel, I guess). If you need a specific example, our "super" box running Scientific Linux 6 didn't have turbo working out-of-the-box (despite it being enabled in BIOS), until I applied the workaround of setting scaling_min_freq to scaling_max_freq in rc.local. Here's its hardware config: http://openwall.info/wiki/HPC/Village > > 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 I thought of compiling more of this into the kernel, but chose to stick with RHEL5's tested configuration for now. > > 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. Aren't we (also) triggering ACPI calls when we actually adjust the settings via sysfs, with acpi-cpufreq having already been loaded? I doubt it makes much of a difference when this module is initialized. > > 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. Unfortunately, they do. > > 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. Why are you saying that "we don't need it for now"? What do you suggest we do instead? > > 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. In a sense, all we do is a waste of time. Alexander
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.