Lucid server flavour RFC

Tim Gardner tim.gardner at
Thu Feb 4 20:50:43 UTC 2010

Tim Gardner wrote:
> I'm considering an additional Lucid x86_64 flavour, one tuned for low
> latency, power consumptive platforms. I've received a fair bit of
> anecdotal evidence that the current Lucid server flavour is not well
> tuned for some workloads. Examples include audio processing platforms
> such as asterisk and mythbuntu. There are a number of folks that have
> requested a higher HZ setting for the desktop as well.
> I expect this kernel flavour will be an elective install, i.e., you'll
> have to install it manually at least once.
> There are 3 knobs that that I know of that can be used to change
> behavior with respect to latency. Unfortunately, one of them requires a
> kernel recompile (hence the new flavour).
> 1) Set CONFIG_HZ=1000. This reduces the user task timeslice to 1 msec. I
> believe this also improves the responsiveness of select() and poll().
> 2) Disable CPU frequency scaling by setting the default governor to
> PERFORMANCE. An alternative is CONFIG_CPU_FREQ=N which leaves the CPU
> frequency setting at whatever the BIOS has set. Note that CPU frequency
> governor settings can be changed at run time (if CONFIG_CPU_FREQ=y).
> 3) Disable the CPU idle governor, or alternatively set 'idle=halt' on
> the kernel boot command line. If the governor is active ACPI can reduce
> the power consumption of a CPU while its in an idle state. However, it
> takes a finite amount of time to fully restore a CPU which therefore has
> an impact on latency.
> Its possible that the CPU and I/O schedulers could also have an impact
> on latency, but both are also run time settable.
> I'm quite interested in your suggestions for improving latency sensitive
> workloads.
> rtg

Andy has pulled my request for a new flavour that includes PREEMPT=y and 

I've had a number of questions about why don't we use the RT kernel. I'd 
be happy to as soon as the rest of the RT kernel patches are upstream 
(in which case there is no longer a need for an RT kernel).

Tim Gardner tim.gardner at

More information about the kernel-team mailing list