Lucid server flavour RFC

[Daniel J Blueman]

Hi Tim,

Increasing CONFIG_HZ from 100 will only benefit kernels which are
configured without CONFIG_TICKLESS (as limited by architecture or
configuration); with tickless, select()/poll() etc all use
asynchronous wakeups, ie not the timer interrupt.

The only things depending on this, I'm told, are timeouts, which are
long anyway. If someone is finding higher latencies with eg audio
hardware, there is good chance it is due to a kernel bug, eg data is
added to a list and processes aren't immediately woken up, but in the
next soft-interrupt following a hard interrupt or other kernel return
- this kind of bug can sneak by for a long time.

The wake-up latency of a server responding to interrupts can thus be
governed by the sleep state exit time - this is a configuration issue,
not kernel build issue - the audio processing package needs to somehow
tell the user/system to disable deeper sleep states etc by eg
activating the performance processor governor when the application
starts. Shipping a different kernel configuration is way overkill I
think...

Unless I'm missing some things?

Just a last point - I was finding less than expected performance,
until I increased the processor ondemand up_threshold to down to 11% -
the default of 50% seems too conservative for wakey workloads.

Hope this helps,
  Dan

---

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
-- 
Daniel J Blueman