Test of the Preemptive Kernel Patch

e8johan writes "Linux was originally written as a general-purpose operating system without any consideration for real-time applications. Recently Linux has become attractive to the real-time community due to its low cost and open standards. In order to make it more practical for the real-time community, patches have been written to affect such things as interrupt latency and context switch. These patches are public domain and are becoming part of the main Linux tree. The test results can be found here."

Comments

Here's the actual results

[GreyWolf3000]

Stolen from the article. Most of it recaps what the average /. developer would already know, so here's the numbers to look at:

| Script | Without Patch | With Patch |
| Find script | 78.51 ms | 0.48 ms |
| Launch script | 0.61 ms | 0.41 ms |
| File move script | 0.62 ms | 0.31 ms |

As you can see and would expect, there's a sizeable improvement.

Re:Question.... (about real-time)

[capoccia]

real time means there is a guaranteed maximum response time. this generally hurts overall performance, but it does reign in the worst case. this is absolutely critical in some special applications, but most situations are better off without real-time.
for example. qnx is a real-time operating system. it's frequently used in embedded systems with only one communication channel. everything that wants to communicate takes its turn and the system kicks it off the line when its time is up. so it is critical that there is a guaranteed maximum response time.

Re:Question....

[aridhol]

Not necessarily even a high-speed process. Real-time means that there are time limits involved. Technically, a payroll system is real-time, but its time limit is rather long (1 pay period).

Note that real-time also means that there may be a minimum delay as well as the maximum delay. In space shuttle controls, for example, if you need to do a 4-second burn, you don't want it to end too early or too late.

Re:A question

[Webmonger]

Generally, being more responsive comes at the cost of being less efficient. They talk about "throughput" a lot, when determining the effects of the preempt patch.

So for servers, preempt is probably not the way to go.

Re:A question

[elfdump]

real-time design techniques always seem to improve system performance.

Making kernel threads preemptible by user processes requires additional management overhead. This overhead translates into less cpu time for processes overall, and hence less throughput. So while high-priority user processes are more responsive with the patch, fewer processes will run to completion in a given amount of time (less throughput).

To instantiate this, you might notice that your mp3s get interrupted sometimes when heavy kernel processes, like a lot of disk reads, are going on. This patch would prevent the kernel from switching out your mp3 player as readily, leading to a smoother desktop experience. However the overhead of managing this new feature means that a heavily-used server will not service a given amount of jobs as quickly.

So if responsiveness is important (desktop) apply the patch. If your apps just need raw cycles (server) the patch either won't have much effect or could slow things down.