Non-Deathmatch: Preempt v. Low-Latency Patch 178
LiquidPC writes: "In this whitepaper on Linux Scheduler Latency, Clark Williams of Red Hat compares the performance of two popular ways to improve kernel Linux preemption latency -- the preemption patch pioneered by MontaVista and the low-latency patch pioneered by Ingo Molnar -- and discovers that the best approach might be a combination of both."
Re:co-op! (Score:2, Insightful)
Re:What's up with the degrading performance? (Score:3, Insightful)
The event which caused the 215ms even probably only happens once or twice per day. Perhaps it was some weird code path that the LL patch didn't touch, or some unlikely combination of events occuring "simultaneously"
Re:What's up with the degrading performance? (Score:5, Insightful)
Embedded systems must have a very high uptime, it's not acceptable to reboot the machine every day to maintain performance.
True that. Which is why the author of that article made the point that combining the two patches is the best way to go, since he ran the torture test for 15 hours and it didn't go over 1.5 msec even once.
Note that for many purposes, a worst-case latency of 1.5 msec is ample. I don't think there is any version of Windows that goes that low; I don't even think BeOS (legendary for low latency) goes that low. As the author noted, if you are driving a chemical processing factory or something like that, you need hard realtime and you should use something other than Linux kernel 2.4.x!
steveha
No argument here, move along. (Score:4, Insightful)
Er... while some misinformed folks have in fact been arguing over "which approach is better," both Robert Love [iu.edu] (preemption) and Andrew Morton [iu.edu] (low latency), the authors of the patches, have agreed since before November that a hybrid approach is probably correct, and it seems to me (though I don't speak for them) that they're faintly embarassed [iu.edu] at the number of True Believers who have stepped up to champion one or the other's side in this nondeathmatch. They're attacking different sections of the same problem.