Linus Pooh-Pooh's Real-Time Patch 262
An anonymous reader submits "Speaking with CNet via email, Linus Torvalds appears to be in no hurry to accept the latest real-time patches from embedded specialist MontaVista into the mainstream kernel, at least not "at this time." Nontheless, MontaVista's new open-source real-time Linux project could broadly expand commercial opportunities for the open source OS, especially in telecom initially, where real-time Linux will likely play on "both ends of the wire." For example, Linux is already making progress in smartphones."
Better link (Score:5, Informative)
RTOS (Score:4, Informative)
Real Time Operating Systems. [wikipedia.org] Now you know!
Re:Patents ? (Score:5, Informative)
A hard realtime operating system is one where calls to the operating system are guaranteed to be executed within a certain timeframe.
Re:Might not be in a hurry.... (Score:5, Informative)
I'd be shocked if he didn't realize exactly how this patch would impact Linux. From the article:Iduno what else there is to discuss...
From LKML (Score:4, Informative)
finally, i went for correctness primarily, not latencies. I checked
out the MontaVista patches and they categorize roughly 30 spinlocks
as the ones that are necessary to be 'raw'. Unfortunately this is
inadequate, my patch excludes 90 such locks and it's still probably
not a 100% correct conversion. The core kernel needs changes in the
locking infrastructure to get rid of most of the these 90 non-mutex
locks.
Re:Patents ? (Score:4, Informative)
Links to better KernelTrap articles/email threads (Score:5, Informative)
Ingo Molnar - a RedHat employee/kernel hacker - has some patches that are similar in scope but different (and most likely preferable from a performance and maintainability viewpoint) in approach.
Read about them here and form your own opinion:
Linux: Real Time Kernel Prototype [kerneltrap.org]
Linux: Realtime Preemption [kerneltrap.org]
Real time Linux could win the house. (Score:3, Informative)
Re:Anyone finding this suspicious? (Score:4, Informative)
Re:Patents ? (Score:4, Informative)
Answer: (Score:5, Informative)
Yes. All the other obscure things which only 0.1% of everybody uses, they are small isolated pieces of code (like some random driver). What we're talking about here is adding lots of highly non-trivial code to the core of linux (you know the kernel/ subdirectory of the kernel source) which only 0.01% of people will actually need/use. So, yes.
I also think it would be quite arrogant of the RT people to expect this to be added without serious thought (and possible reworking). (NOTE: I'm not saying they do/did expect it to, just that it would be arrogant to do so)
The Linux kernel is too monolithic for this (Score:5, Informative)
If you want hard real time and protected mode, you need an architecture like that of QNX [qnx.com], where almost everything runs in user space. File systems, drivers, and networking are all user programs, intercommunicating by message passing. The kernel only handles CPU dispatching, memory management, and message passsing.
In an architecture like that, everything in user space is preemptable, without any extra work in the system services. There are no long latencies in the QNX kernel; they were all taken care of years ago.
As Linus points out, though, few consumer embedded devices really need hard real time. Most media-related stuff can paper over delays with buffering. A classic comment is, "You run your web server on Linux. You run your nuclear reactor on QNX".
Automotive systems, though, really need it. QNX is big in that market.
LKML reference (Score:4, Informative)
Re:It is the scope and magnitude of the patch (Score:5, Informative)
Note also that the patch hasn't really even been submitted for inclusion. The Montavista people posted it to LKML with a lot of warnings, making it clear this was intended as a way to get early feedback on the direction of their project, rather than as an example of a finished implementation.
So the slashdot headline is more than a little misleading; everybody agrees this is early in the process, and it's no suprise no-one's rushing to apply the patch.
--Bruce Fields
Re:Real Time enhancements as a fork (Score:2, Informative)
1: Cut Head Open
2: Poke brain with stick
3: Close Brain.
It's just a little harder than you make it out to be. Look how many of the subsystems have to be touched by this driver.
Re:Linus is right. (Score:3, Informative)
Just to fight this stupid urban myth: The GPL doesn't say that. Please read at least the FAQ [gnu.org]. kthx.
Re:Linus is right. (Score:2, Informative)
If you read MontaVista's original announcement, it was not posted for inclusion in the mainstream kernel, no one (including MontaVista) is claiming that it is ready. They merely posted their work to stimulate discussion and to avoid duplication of effort. So of course Linus is right, no one ever said it _should_ go in the kernel now or even anytime soon.
Why was this modded "Insightful", the poster clearly has not bothered to understand the situation.
Re:What's a spinlock? (Score:5, Informative)
while (CheckOKtoProceed());
You see, the program "spins" until CheckOKtoProceed() returns true. The alternative is a call to a Yield(), Wait() or Sleep() function that 1) blocks execution until some condition is satisfied, and 2) tries to yield control to some other pending process while that is happening.
The trouble with a spin lock is that it hogs the processor. The trouble with the other kind of lock is that it allows another process to proceed, but it may not be safe to allow that on account of a data structure not being in a coherent state of update. A mutex is a kind of lock that by agreement of its use allows only one such process to proceed. A non-mutex lock doesn't offer such protection.
The argument is that the proposed modification make the kernel much more preemptable and do less spin locking that can kill response, but each element of the proposed modification would need to be checked and tested very carefully that after the change there aren't issues regarding the protection of data structures from multiple processes that could change it along with all kinds of mind-bending subtle bugs that can arise.
Re:Might not be in a hurry.... (Score:3, Informative)
Actually, the article hints at Linus' mastery of the issue by clueing the reader in on a few consequences of hard real time systems. The problem is that while the OS would be capable of guaranteeing a response within tens or hundreds of microseconds, the overall response time of the system is reduced. Linus is quoted as saying he believes most people, even in the embedded space, don't want this as a standard feature of the OS. This is because there's a comparatively easy fix for getting quick response times: over-provision the hardware.
For HRT systems, however, it's not good enough that the response time is "probably good enough, most of the time." HRT systems require a guarantee, and that guarantee has a net effect of slowing down the system.
Compare it to "guaranteed-secure" encryption. It's possible (quantum encryption), but it requires a physical fiber connection (a polarized light-pipe) and some serious detection hardware.
The article goes on to say that Linus may consider putting pieces of the patch into the kernel in the future.
Re:Anyone finding this suspicious? (Score:2, Informative)
However, it goes away if your CMOS battery dies. (I believe it's SRAM based.)
I suspect you're thinking of FLASH memory, which isn't as fast as SRAM, or, generally, even DRAM.
Here's a good overview [arstechnica.com] on DRAM and SRAM, if you're interested.
Re:Alternatives? (Score:3, Informative)
RT-Linux (and RTAI which is roughly based on RT-Linux but offers a different API) is very different. It runs as a hard real-time micro-kernel which takes over your system and then runs all of Linux as a thread. When you run your hard real-time code it runs in that micro-kernel space rather than Linux user or kernel space. All of Linux gets preempted by your software.
Here [disca.upv.es] is a great article covering this subject in more detail with tons of links.
Re:The Linux kernel is too monolithic for this (Score:3, Informative)
This is where the Linux architecture, with drivers in the kernel, really bites you. Because all the drivers have to be made preemptable, too. This is at odds with the traditional UNIX "top and bottom" driver architecture, with the "top" running as a process and the "bottom" running at interrupt level.
Actually the Linux architecture isn't as bad as you imply in this respect. Although Linux does follow the traditional top/bottom separation (though in Linux terminology, at least, the "bottom" half is the part that runs in a kernel thread and the "top" is at interrupt level), the fact that the kernel itself is now preemptable means that the bulk of driver code is preemptable.
The code that runs at interrupt level is not preemptable (except by non-maskable interrupts), but it is kept as tiny as possible. The "bottom half" code (implemented using "tasklets" these days) is all fully-preemptable except where it explicitly turns off preemption. Those sections are gradually being eliminated. In addition, low latency work is finding and eliminating sections of code where the kernel does any kind of extended processing without scheduling.
This doesn't mean that Linux is a RTOS, but it's a lot closer than you'd expect of a mainstream OS, and it's getting better all the time. QNX has a non-preemptable kernel so lots of stuff has to be in userspace to be preemptable. Linux leaves it in the kernel, and preempts it there. Same net effect.
There are no long latencies in the QNX kernel; they were all taken care of years ago.
Linux can't say this, of course, but it's getting there and will probably be able to make the same claim in a few years.
You run your web server on Linux. You run your nuclear reactor on QNX
And Linux may never be the best choice for hard real-time. But it will certainly be a reasonable choice, soon.