why did Ubuntu turn off kernel preemption in Edgy?

[Ulrik Mikaelsson]

First of all, I'd like to clear up what I believe to be a few
misunderstandings here.

First of all, for all the ones experiencing sound hickups under
I/O-load; you issue most likely have nothing or at least very little
to do with either preempt or the timer interrupt. Back in 2.4 very
modest hardware already could perform sound-playback and disk-i/o
simultaneously without problems. In fact, at the time (99-ish), that
was one of Linux big strengths compared to both Mac and Windows. If
you're having problems with I/O-interference your most likely source
is the driver. For some SATA-controllers I know 2.6.17 had issues, I
experienced them personally, and 2.6.19 distributed right now with
Feisty helped, at least myself. Possibly, the io-scheduler can help
you a little too, with a buggy I/O-driver, it's my experience that the
noop-scheduler often performs best. (Believe it or not) And remember,
do some kind of FS-bench, rather than hdparm if you want to bench it,
and remember to flush you I/O-cache.

Karoliina, regarding you issues with audio-latency, PREEMPT and 1000
hz most certainly will help, but talking latencies of 100msec, I would
most likely think your issues is also either driver-related, or due to
applications making bad assumptions. Using reasonable
process-priorities and sensible code, I would think an application
using stock Ubuntu kernel, on 250 hz and voluntary preemption should
be able to reach at least execution 1/4 of the intervals, giving a
latency of  16 ms. When talking professional audio HW and SW, though,
my guess is they use the RTC-devices instead, which is out of my
knowledge, but should be unrelated to what the interupt timer is set
to. Windows, for instance use a default interrupt timer of 100hz [2],
so I would guess if you got 2-3ms latency out of you system in
windows, it definately wasn't thanks to the interrupt rate.

Regarding custom kernels, though, I absolutely agree there are reasons
to provide common differing kernel configurations for specialized
needs. Regarding interrupt rate, laptops isn't the only case where
lower interrupt rates are desirable.
* Increased interrupt rates also increases the load, and AFAIU that
increase grows exponentially to the actual load.
* Allegedly, interrupts rates become problematic when dealing with SMP
or mutli-core systems. Why exactly is above my comprehension, but I've
seen this first-handed in one case.
* Virtualization becomes difficult with higher interrupt rates, since
several OS:s running on the same hardware will further increase the
interrupt yield, causing the system to ultimately start loosing
interrupts. [3]

Based on this, I would say that any powerful machine with hard latency
requirements, such as a hard-core gaming and audio/video-production
would benefit from a high interrupt rate, while laptops, servers and
"weaker" machines where battery life or throughput is more important
than latency, lower interrupt rates is highly advised. (Maybe even as
low as 100hz?)

References:
1. http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks
2. http://en.wikipedia.org/wiki/Scheduling_%28computing%29
3. http://kb.vmware.com/KanisaPlatform/Publishing/329/1420_f.SAL_Public.html

Now please bash me for all my misconceptions and errors. ;)

Regards
/ Ulrik

On 11/27/06, Phillip Susi <psusi at cfl.rr.com> wrote:
> Karoliina Salminen wrote:
> > Why the 1000 Hz couldn't be used?
> > I could put it this way:
> > CPU overhead raises from 0.1% to 1%. Who can notice that?
>
> The reason why a high timer rate is bad is that it interferes with the
> cpu's low power states.  Entering and leaving the lower power states has
> a fairly high latency, so to make good use of them you need to enter the
> lower power state during an idle period, and the cpu must remain there
> until there is actual work to be done.  When it takes the cpu 250 us to
> enter/exit the lowest power state, and you are getting a timer interrupt
> every 1000 us, you can only spend half the time in the low power state
> at most.  Ideally if the system is actually idle the timer interrupt
> should be suspended when it switches to low power mode, or at least set
> to the longest delay possible given the current list of pending alarm
> events.  That way the cpu isn't constantly waking up just to increment
> the current time.
>
> Oh, and please don't trim CC lists, use reply-to-all.
>
>
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>