[lkml]   [2004]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

* Andrew Morton <> wrote:

> None of these approaches improves worst-case latency at all on SMP.
> If we're not going to address the SMP problem we could just make it
> UP-only, in which case increased locking costs are a non-issue.
> I'd prefer that we find a solution for SMP too though.

i have solved the fundamental SMP latency problems in the -Q7 patch, by
redesigning how SMP preemption is done. Here's the relevant changelog


the main change in this patch are more SMP latency fixes. The stock
kernel, even with CONFIG_PREEMPT enabled, didnt have any spin-nicely
preemption logic for the following, commonly used SMP locking
primitives: read_lock(), spin_lock_irqsave(), spin_lock_irq(),
spin_lock_bh(), read_lock_irqsave(), read_lock_irq(), read_lock_bh(),
write_lock_irqsave(), write_lock_irq(), write_lock_bh(). Only
spin_lock() and write_lock() [the two simplest cases] where covered.

In addition to the preemption latency problems, the _irq() variants in
the above list didnt do any IRQ-enabling while spinning - possibly
resulting in excessive irqs-off sections of code!

-Q7 fixes all of these latency problems: we now re-enable interrupts
while spinning in all possible cases, and a spinning op stays
preemptible if this is a beginning of a new critical section.


feedback from Mark H Johnson:

the latest patch is:

i'm already in the process of cleaning up the patch and making it ready
for splitup & merge. The spinlock fixes will be amongst the first
patches i'll send you.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.106 / U:20.280 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site