The beginning of the realtime preemption debate
Posted Jun 3, 2005 6:58 UTC (Fri) by jwb
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.
to post comments)