MontaVista's reply (Score 5)

I'll try to answer/respond to the most significant questions and points made here. 1. 2.5 is the next "development kernel", and is clearly the right place to initiate a fundamental kernel change such as preemptability. 2.6 is the right place for commercial usage, obviously. 2. Preemptibility means the systems can and will stop a process running in kernel mode and switch to a higher priority newly executable process. For more, including specifics of what our prototype does and how we want to advance it...read our white paper! Here isn't the place to repeat those details. 3. We are not dogs, but after a few beers or missed shots on the pool table we do howl alot. 4. We actually did initial work on 2.2.14 but our primary goal is proving out this technology, providing to customers who may need it, and offering back as a technology for 2.5 (->2.6). Hence, 2.4 was and is the proper base, given that we think we can have production ready software early next year, "long after" 2.4 is cooked. We feel releasing a prototype on 2.4-test software is okay. 5. A preemptable kernel is not a rate monotonic scheduler! We also offer a scheduler that sits on top of (runs before) the standard Linux scheduler that does a good job of selecting/dispatching real-time processes very quickly and with fixed overhead. It's not rate monotonic, it's a simple priority driven scheduler. 6. I won't engage in arguing the pro's and con's of "one man's control of an OS". It is the way it is. MontaVista lives with it and is trying to work with it. We think a preemptible kernel design, leveraging the SMP locks, is a good next step for the Linux kernel and benefits all "market segments" (types of users). We want to prove it with real software, and this is our starting point. We are "releasing early, releasing often", amen. 7. "these guys proposal was regeted"...I reget to tell you that you misunderstand. What was "rejected" was a set of patches that injected preemption points, which is a fundamentally different technology than what we've implemented. We have not proposed or submitted anything as of yet, beyond making our current prototype available. 8. Fross, THANK YOU. 9. Inclusion in 2.4 is absurd, it's time for it to stabilize, finalize and start getting deployed. 10. Most of the systems that Hard Hat Linux get designed into aren't serving "multiple users". They are control oriented environments. In such environments, having a design ability to assure that high priority tasks get cycles very quickly, with assurance, and all the cycles they want until they are "done", is critical. We are trying to enable that capability. Superuser privileges usually protect real-time priorities from casual mis-use on multi-user systems. 11. RTAI and RTLinux are "sub-kernels" which provide a lower level multi-tasking environment, a small set of services (mostly around synchronization and passing data to/from higher level Linux processes), and which virtualize interrupt off/on operations in Linux. Basically, they provide a multi-threaded interrupt handling environment with better worst case interrupt off characteristics. There are limitations to such an environment. A preemptible Linux kernel attempts to improve PROCESS responsiveness in Linux proper (as opposed to attached a small underlying, separate multi-tasking environment). They are quite different. They are not in conflict, and even with excellent preemption performance, a system can still benefit from improved interrupt responsiveness via use of RTLinux. 12. MontaVista did not request/support the request for preemption point inclusion in Linux. The perspective of our real-time team is that preemption points are NOT a desirable long-term technology, and we don't support their inclusion in Linus's kernel. 13. Everything MontaVista develops on our own dime is released as GPL or LGPL software. Everything to date anyway, and we don't see that changing anytime soon. Even most of what we've been paid to develop user professional services has been GPL/LGPL licensed (with our customers approval of course), as it's turned out. We are dedicated to the values of open source. We're a Linux company for gosh sakes! 14. Minimizing throughput impact on a uniprocessor is important. There are opportunities for throughput improvement under busy workloads...very simple workloads won't improve and could degrade, the questions are how much, and is the tradeoff worth it in order to get responsiveness/consistency of high priority behavior. Exploring, proving and educating in this area is an important component of our prototype work. 15. No our prototype doesn't yet support SMP. The cost of synchronizing across processors using the SMP locks shouldn't be more than synchronizing across processors using the SMP locks...don't know where you are coming from suggesting what we are doing will be prohibitively expensive on a multiprocessor! We'll share an SMP version when we get one put together (but it's not highest priority for us, our first order target for this thing is uniprocessors, which are far more prevalent in the embedded market segments.) 16. This is available for an IA32 platform. If you think that's an obscure platform...I guess you live in a parallel universe where Motorola hardware got selected by IBM back in the early 80's for their PC, or something! We'll productize on all supported MontaVista platforms (21 different boards across 4 different architectures as of our 2.1 release 2 weeks ago...). 17. I'm not aware Ingo did fully preemptable kernel work, and if Ingo did any work on such a system, we weren't aware of it and did not base this on any such work. 18. Preemptible is not interruptable. We've separately and previously done characterization work on interrupt off times in Linux. See our real-time project area on our web pages (www.mvista.com). Interrupt off times in Linux are surprisingly good, with one exception (child process exit with many children)...and of course ignoring arbitrary drivers that can misbehave. 19. Time to go howl... Sorry to be long winded. I hope this helps to clarify a few things. -Kevin