Non-Deathmatch: Preempt v. Low-Latency Patch

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!

[lightfoot jim]

I hope you're kidding! In a co-op system, each program monopolizes all the resources of the machine until it voluntarily gives up control. If the instruction to return control to other processes is preceded by instructions which could result in an infinite loop or wait state, the machine is then inaccessible. Situations like this exist in preemptive systems as minor annoyances. For example, if you ssh from and openBSD machine to a sshd server and then pull the network cable from the sshd server, the tty on the openBSD machine will stop responding to input. Since the BSD kernel is preemptive, you can switch tty's and just kill the process of the frozen tty. In a coop setup, the key sequence to switch virtual consoles would be ignored and you'd have to reboot the machine.

Re:What's up with the degrading performance?

[dmiller]

It has got nothing to do with how often the machine is rebooted and everything to do with the frequency of latency increasing events.

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?

[steveha]

Well, to be precise, the worst-case value "degraded". And I'm not sure "degraded" is the correct word. With a huge torture load put on the kernel, during a 15-hour interval, at least once the latency value was 215.2 msec. This could mean that there is a possible latency condition that happens under torture load approximately once every 15 hours. It could also mean that after 15 hours, your chance goes up so it could happen much more often than that, but we don't know that. It could even mean that there is a possible 215 msec latency condition that happens under torture load approximately once every 30 hours, and it happened to occur during the first 15 hours.

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.

[Chops]

From the article:

Back in early November 2001, I started following a discussion between two factions of the Linux kernel community ... There were two main factions, the preemption patch faction and the low-latency patch faction. Both groups were very passionate (i.e. vocal) about the superiority of their solution.

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.