Slashdot Mirror
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."
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.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
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.
Whenever you have to control a high speed process, you need real-time. No, it doesn't mean 'live', but instead it relates to situations where you have hard timing limits that you have to meat for things to even work. Single session CD-writing is a good example, if your application/OS combo doesn't meat the hard real-time deadlines related to how fast the physical disc is spinning, you've just wasted the media blank and have to start over. In many real-time applications, not meeting the timing can mean the equipment may be dammaged or destroyed, possibly in a manner dangerous to anyone standing around operating it. A lot of times it is more an issue of quality suffering, so real-time is more of a desirable target than an absolute necessity.
If these patches are applied when they aren't really needed, how much does it impact the system's performance and stability? I read in the thread shown that it conflicts with SMP, so you'd want it turned off for installs on multiprocessor systems, but aside from that, why can't it be turned on by default?
I understand the concept of real-time and hard real-time vs. "soft" real-time, so I'm not totally ignorant. But, what I don't understand is why one would not want real-time characteristics in an OS? In other words, from my uninformed perspective, real-time design techniques always seem to improve system performance. Therefore, it looks to me like we would always want this to be part of any OS we use.
No? If not, why not?
(I guess one of my assumptions here is that real-time techniques always lead to faster systems.)
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
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.
I can't say that I don't give a fuck. I've just run out of fuck to give.
AmigaOS used round-robin priority-based pre-emptive multitasking with an exokernel architecture. It was also designed initially for a processor with no concept of privelege levels (or even memory management), the 68000. Those facts meant that the AmigaOS was a real-time OS *if programmed correctly*. On the other hand it was possible for a program to take over the whole machine, turn of multitasking and do its thing with a blatant disregard for other tasks.
The responsiveness of AmigaOS actually comes from the fact that the process with the highest priority was the input.device task which was responsible for sending IDCMP (window) messages to other tasks. This task was also capable of giving some visual feedback on buttons, etc. (which was later extended using BOOPSI to allow arbitrary code to be run when a button was pressed, etc.). Hence there was this task that would generally preempt any other task that was running just to give GUI feedback. And *that* is why the Amiga appeared so responsive! Start a task at priority 30 that just runs an empty loop and the machine will appear to have locked up.
It takes the preemptive and low-latency patches
to make the linux kernel suitable for general-
purpose use on low-powered hardware. If you want
to watch smooth mpeg decodes while running a POVRay
job and serving web pages out of a database,
it takes a top-end current box to keep you happy,
unless you have preemptive and low-latency patches
applied.
Multimedia *is* realtime, so general-purpose implies
realtime.
-I like my women like I like my tea: green-
Your definition of a real-time system is a little too loose. A payroll system is not a real-time system. Sure, the employees might get angry if the payroll is not submitted on time, but a hard real-time system has well-defined fixed time constraints, and guarantees that these critical tasks will be completed on time. A payroll system makes no guarentees.
I have to side with the original poster. Other than scale, there isn't any difference between a payroll system and something you would typically consider "real time". There are "well-defined fixed time constraints" for payroll processing (in the US often defined by state and federal laws). If you do payroll processing, you guarentee (often contractually) that you will meet the constraints.
In both cases, there are time limits expressed in terms of the outside world("real time"), and sufficient consequences if these constraints are not met to define failure to meet the constraints as system failure. The only difference is scale.
-- MarkusQ