Linux Kernel Goes Real-Time

Several readers wrote to alert us to the inclusion of real-time features in the mainline Linux kernel starting with version 2.6.18. (Linus Torvalds had announced 2.6.18 on September 19.) Basic real-time support is now mainline. This will ease the job of developers of embedded Linux applications, who for years have been maintaining real-time patch sets outside of the mainline kernel. The announcement was made by TimeSys Corp., a provider of developer services. Much of the work was done by Thomas Gleixner at TimeSys and Ingo Molnar at Red Hat.

Comments

What about media?

[stonedyak]

The article only talks about these new patches from the embedded devices point of view. So can anyone tell me if these new features would be useful for improving the responsiveness of media applications in Linux? I'm talking about video/audio playback, as well as authoring and recording.

What other benefits would the desktop see from this?

Re:What about media?

[fossa]

But desktop users, or at least me, don't care about doing things "fast". I care about things feeling fast. I care about latency. So, do these patches help the audio on my computer not skip when I move a window? I've tried the premptive kernel patches in the past with no noticeable difference. How are these patches similar, different, or complimentary to Ingo Molnar's (whose patches are mentioned in the article). Thanks.

Re:What about media?

[novus ordo]

You are right, to a certain extent, but take audio/video work as an example. If I am using my computer as a synthesizer, I want to be able to hear the keys as they are being pressed, not 0.5-2 sec later. Even if the mixing part would take longer than the time I press my next key, the kernel should process that key anyway. Music is a weird thing.. a couple of milliseconds difference is enough to change the perception of a note. So in this case, it will 'seem' faster, even though it will have less throughput(context switches the mixing process out even though it has the mixing data in the cache which conveniently gets invalidated, swapped, etc.) I guess it gives certain applications the super-duper dependent on time factor that would otherwise be overlooked in the ways kernel measures "fast."