LWN: Comments on "The beginning of the realtime preemption debate"

The beginning of the realtime preemption debate

mingo — Thu, 21 Jul 2005 10:22:10 +0000

yes, priority inheritance is part of the PREEMPT_RT patchset.

The beginning of the realtime preemption debate

huaz — Fri, 10 Jun 2005 00:59:49 +0000

Kernel preemption itself is not a guarantee of hard real time. What about priority inheritance? Is is addressed in the RT patches?

The beginning of the realtime preemption debate

set — Fri, 03 Jun 2005 07:43:55 +0000

The 'audio people' are not driven by xmms playback issues, although the
general userbase would benifit from their concerns. They want to be able
to record live sessions and do live performances without drop outs or
clicks, which are show stoppers. This extends to live effects processing
and multimedia capture of all sorts. And the RT patch is completely
optional. It should have zero effect if you dont config it. The debate
is not about how this patch would affect the majority, but if it is the
best solution for a broad range of problems, which, if you read the
ungodly long thread on lkml, seems to have goosed a number of parties,
armchair and otherwise.

Actually, the issue I would rather have seen presented here would be about
the argument about what exactly 'real time' means. For example, some backers of the RT patch are saying it is better than RTOS's they are using
in their industry, and that it is potentially earthshaking. The adjective
'hard' when combined with 'real time' seems to be where the semantics
get difficult.

And no one even mentioned the patent fud;)

The beginning of the realtime preemption debate

jwb — Fri, 03 Jun 2005 06:58:23 +0000

What's with the car brakes argument? I could probably implement a braking system in 100 lines on
an AVR. I'm not sure why I'd use a microprocessor and millions of lines of kernel code.

I wish the audio people would solve the problem differently. They should be able to pin their
processes exclusively on one or more CPUs, leaving the rest of the lower-priority tasks fighting over
the remaining CPU or CPUs. This might even be possible with the scheduling domains patch. I'm
worried that the people who want XMMS to not skip when they mkfs a 2TB device while playing
Quake are going to screw up the kernel for other users. Linux has a history of making basic
operations like syscall, i/o, schedule, and fork cheaper with each release. The RT work tends to
make basic operations more expensive, which isn't going to put a smile on the face of your local
mail server sysadmin. I'm going to go way out on a limb and guess that there are at least 1000
network server instances for every instance of Linux in audio performance roles.

Now I'm not suggesting that the majority should rule, but Linux has normally been able to
accomodate weird use cases without compromising the mainstream. And that's what I'm hoping
shakes out of the RT debate.

Talking past each other...

wa1hco — Thu, 02 Jun 2005 15:45:16 +0000

Realtime discussions devolve into endless debates _because_ each party defines their interests differently: Soft realtime, Hard realtime, Provable realtime, desktop use, audio use, braking use, aircraft use, etc. etc. For a more productive conversation, we need to develop consistent terminology and recognize the value of other applications.

The nanokernel debate reminds me of the old RISC vs CISC debate. RISC attempted to use simplification to enable faster execution, but then the CISC people (Intel, et al) proved that with some effort, CISC can run as fast or faster than RISC. RISC really only offered a way to do fast _low budget_ cpu's

Nanokernel advocates seem to make a similar argument. They have a low budget (less complex) way to get real time. If the analogy holds, Ingo's patch will, with some extra effort, provide a way to address realtime requirements with as good or better performance.

The beginning of the realtime preemption debate

simlo — Thu, 02 Jun 2005 09:32:53 +0000

Oh no! Don't start that discussion here as well! It is really long and heated on lkml already! I will dear to add that I disagree, but I will refer to lkml for the arguments.

Some day, someone will hopefully post a comparison between PREEMPT_RT and RTAI, wrt. how well it works wrt. latencies and performance, and how much work you need to put in to actually use it on _real_ projects.

It's just sugar...

xoddam — Thu, 02 Jun 2005 07:16:49 +0000

Git was born small and almost perfectly formed. Current development is a
matter of "sweeten to taste".

The beginning of the realtime preemption debate

aleXXX — Thu, 02 Jun 2005 06:46:54 +0000

I really think RTAI (or the L4 stuff) are a better alternative, or at
least they can provide a way to provide "real" realtime together with
linux. What's actually the current state of RTAI with kernel 2.6 ? Which
architectures are supported ?

Alex

Whatabout Git?

bronson — Thu, 02 Jun 2005 03:30:34 +0000

No Git news this week? Git Traffic appears to have died the day it was created.