Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 29 Jun 2014 12:08:33 +0400
From: Solar Designer <>
Subject: Re: CPU power management

On Thu, Jun 12, 2014 at 08:51:03PM +0400, 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:

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

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.


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.