The beginning of the realtime preemption debate

Posted Jun 3, 2005 6:58 UTC (Fri) by jwb (guest, #15467)
Parent article: The beginning of the realtime preemption debate

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.

The beginning of the realtime preemption debate

Posted Jun 3, 2005 7:43 UTC (Fri) by set (guest, #4788) [Link]

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;)