[lkml]   [2001]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: low-latency patches
On Sat, 2001-10-06 at 02:05, Bob McElrath wrote:
> [...]
> Correct me if I'm wrong, but the former uses spinlocks to know when it can
> preempt the kernel, and the latter just tries to reduce latency by adding
> (un)conditional_schedule and placing it at key places in the kernel?

Correct. The low-latency patch does some other work to try to break up
huge routines, too.

> My questions are:
> 1) Which of these two projects has better latency performance? Has anyone
> benchmarked them against each other?

I suspect you will find a lower average latency with the preemption
patch. However, I suspect with the low-latency patch you may see a
lower maximum since it works on some of the terribly long-held lock

In truth, a combination of the two could prove useful. I have been
working on finding the worst-case non-preemption regions (longest held
lock regions) in the kernel.

> 2) Will either of these ever be merged into Linus' kernel (2.5?)

I hope :)

> 3) Is there a possibility that either of these will make it to non-x86
> platforms? (for me: alpha) The second patch looks like it would
> straightforwardly work on any arch, but the for it is only in
> arch/i386. Robert Love's patches would need some arch-specific asm...

Andrew's patch should work fine on all platforms, although I think the
configure statement is in the processor section so you will need to move
it to arch/alpha/

The preemption patch has a small amount of arch-independent code but we
are working on supporting all architectures. 2.5...

Robert Love

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 13:04    [W:0.092 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site