Slashdot Mirror

← Back to Stories (view on slashdot.org)

Test of the Preemptive Kernel Patch

Posted by michael on from the test-twice-cut-once dept.

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."

28 comments

  1. Question.... by hawkbug · · Score: 1

    Can someone PLEASE explain what is meant by real-time applications? Am I supposed to assume that the apps I've been using for the last few years are fake-time applictions? If I were to guess what real-time is supposed to mean, I would guess it means 3D rendering apps or something, but since the author didn't explain it, and I don't already know, I hope someone can help me.

    1. Re:Question.... by Gerry+Gleason · · Score: 5, Interesting

      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.

    2. Re:Question.... by Anonymous Coward · · Score: 0

      That would make a great "Ask Slashdot" in its own right.

    3. Re:Question.... by aridhol · · Score: 5, Informative
      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.

      --
      I can't say that I don't give a fuck. I've just run out of fuck to give.
    4. Re:Question.... by aePrime · · Score: 2, Interesting

      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. Whereas a soft real-time system schedules critical tasks over other tasks, and the task retains its priority until it is complete. If you run a payroll system, it will not use all of your system resources until the pay day comes.

  2. title by tps12 · · Score: 0, Offtopic

    Is it just me, or does the title of this story sound like a Harry Potter book?

    --

    Karma: Good (despite my invention of the Karma: sig)
  3. Here's the actual results by GreyWolf3000 · · Score: 5, Informative

    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.
  4. Re:Question.... (about real-time) by capoccia · · Score: 5, Informative

    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.

  5. Leave it on? by TheSHAD0W · · Score: 5, Interesting

    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?

  6. A question by Da+VinMan · · Score: 4, Interesting

    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!
    1. Re:A question by Webmonger · · Score: 5, Informative

      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.

    2. Re:A question by elfdump · · Score: 2, Informative
      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.

    3. Re:A question by Pseudonym · · Score: 2

      It depends on the server. Serving streaming media is a fundamentally real-time job, for example. So is ATM switching, not that most servers have an ATM NIC, of course.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  7. Batch, another category by Gerry+Gleason · · Score: 2

    You could look at longer term constraints like meeting payroll as a real-time constraint, but you're right, the deadlines are not really hard. Typically this type of processing falls into the 'batch' processing category which has some interesting parallels to real-time, but with a much longer time-scale. There is very little true batch processing any more, but it used to be the dominant model for most business data processing.

  8. Amiga by jafuser · · Score: 1, Offtopic

    How did the Amiga Operating System rate on this matter? It always seemed to be very responsive even when heavily loaded down...

    --
    Please consider making an automatic monthly recurring donation to the EFF
    1. Re:Amiga by atomice · · Score: 4, Interesting

      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.

  9. Preemptive *is* general purpose by aminorex · · Score: 4, Insightful

    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-
  10. Real time linux vs. WinCE .NET by OldMiner · · Score: 0, Offtopic
    Since we recently had a nearly formal debate about this matter in my operating systems class, I thought I'd post some of the information I dug up comparing Windows and Linux (specifically in the embedded environment).
    • WinCE .NET/WinXP Embedded XP Embedded is not practical for many applications, not the least of reasons for this being that it has no real time support and only runs on x86 processors. So if you want to go Windows and RT, you have to use WinCE
    • Pricing Finding information about the price for WinCE is mildly difficult. I couldn't find any rates published on the web, but instead a list of suppliers. A called one and asked. About $2,663 for the original license and developer software wuth about $14 per copy of WinCE. I honestly doubt this would significantly impact the cost of any development.
    • Development Code for WinCE generally has to be specially developed for WinCE; it can not be recycled from other Windows apps. Non-real time linux applications can normally be used directly in a linux RT environment.
    • Worst-case latency WinCE apparently had a worst case latency of 30.8 microseconds on an x86 according to a somewhat dense report listed on Microsoft's website. Granted, an x86 is a somewhat unfair platform on which to test anything's latency. According to one maker of a real time linux system, latency is about 15 microseconds. The article for this story, however, finds a worst-case latency on a PowerPC to be on the order of .48 milliseconds or 480 microseconds. Ouch. That's pretty bad.
    --
    You like splinters in your crotch? -Jon Caldara
    1. Re:Real time linux vs. WinCE .NET by ocelotbob · · Score: 1
      According to one maker of a real time linux system, latency is about 15 microseconds. The article for this story, however, finds a worst-case latency on a PowerPC to be on the order of .48 milliseconds or 480 microseconds. Ouch. That's pretty bad.

      Apples and oranges. The RTLinux system is totally different from the Pre-emptive kernel patch. RTLinux is designed for Realtime, preemptive services, and from what I understand, is a fairly heavily tweaked kernel, the Preemptive patch was designed more to give a bit more response to a mostly stock kernel - for times when you need responsiveness, but don't want to pay the massive performance hit for getting response right here, right now.

      --

      Marxism is the opiate of dumbasses

  11. I beg to differ by MarkusQ · · Score: 3, Insightful

    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

    1. Re:I beg to differ by TheConfusedOne · · Score: 2

      I think you're mistaking the fact that the final product has a time constraint versus the processing having a time constraint.

      Almost every program has some time constraint involved in it. Not every program has to perform a particular cycle of steps every 10 seconds. Real time usually has to do more with interrupting things in order to meet time constraints (hence the pre-emptive kernel patch). That means that when you program something in real time and say this activity has to happen every five seconds then at that five seconds everything else will be interrupted in order for that activity to occur. (There are of course constraints based on internal timing.) A payroll system has no such constraint. While there are deadlines for people to finish or start activities in the system it doesn't pre-empt any activities.

      --
      --- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
    2. Re:I beg to differ by aePrime · · Score: 1

      We're not talking about human deadlines as time constaints. We're talking about real-time operating systems.

      Taken from Operating System Concepts by Silberschatz, Galvin, and Gagne, "A real-time system is used when rigid time requirements have been placed on the operation of a processor or the flow of data; thus, it is often used as a control device in a dedicated application."

      "A real-time system has well-defined, fixed time constraints. Processing must be done within the defined constraints, or the system will fail. For instance, it would not do for a robot arm to be instructed to halt after it had smashed into a car it was building."

      Look at this as saying that the process must be given CPU time to insure that it completes within its time constraint. This is not the case for the payroll system. The payroll system does not require all of a CPU's attention. While you may have to get payroll in by Friday, it's not a rigid time contraint. Anytime on Friday will do just fine.

      Some examples of real-time systems that they list are systems the control scientific experiements, medical imaging systems, industrial control systems... .

    3. Re:I beg to differ by MarkusQ · · Score: 2

      aePrime: We're not talking about human deadlines as time constaints. ... For instance, it would not do for a robot arm to be instructed to halt after it had smashed into a car it was building

      The only reason that it is unacceptable for the robot arm to be instructed to halt after it has smashed into the car is that the cost of it's doing so is greater than we are willing to accept and still say that the system is working. Consequently, we say that the system fails if it does not meet the constraint. Exactly the same statement may be made of a payroll system (we define the system to have failed if it has not produced the checks by the statutory deadline, posibly adjusted by some margin of safety).

      aePrime: Look at this as saying that the process must be given CPU time to insure that it completes within its time constraint. This is not the case for the payroll system. The payroll system does not require all of a CPU's attention.

      TheConfusedOne: Real time usually has to do more with interrupting things in order to meet time constraints (hence the pre-emptive kernel patch). That means that when you program something in real time and say this activity has to happen every five seconds then at that five seconds everything else will be interrupted in order for that activity to occur. (There are of course constraints based on internal timing.) A payroll system has no such constraint. While there are deadlines for people to finish or start activities in the system it doesn't pre-empt any activities.

      It's a question of the longest time slice a process can tie up the processor compared to the resolution of the hard real-time constraints. As long as a process can't hang the system, the largest time slice is a function of processor speed. Back in the days of slow hardware, we certainly did pre-empt things to run payroll.

      You both seem to be thinking that "real-time" means "fast" when in fact it means that the time constraints are specified with regard to the outside world (thus the phrase "real time"). It doesn't matter if we're talking eons or fempto-secconds, as long as we define success or failure in terms of real world, physical time instead of some internal metric such as processor time.

      Of course, the challenge is at the edges, dealing with very small time windows, very long up times, and so forth, and thus these are the things you'll hear people talk about. It's the same in any field. You won't find many cookbooks that devote a chapter to boiling rice, but it's still cooking. And payroll processing is still a real-time application.

      -- MarkusQ

    4. Re:I beg to differ by MarkusQ · · Score: 2

      See my response to aePrime.

      --MarkusQ

    5. Re:I beg to differ by aePrime · · Score: 1

      You both seem to be thinking that "real-time" means "fast" when in fact it means that the time constraints are specified with regard to the outside world (thus the phrase "real time"). It doesn't matter if we're talking eons or fempto-secconds, as long as we define success or failure in terms of real world, physical time instead of some internal metric such as processor time.

      I never mentioned fast. You seem to be missing the underlying definition of a real-time system. If you know of a payroll system that runs on a real-time operating system, I would love to hear about it. It would pretty much mean that the only thing that operating system is used for is payroll.

      Real-time systems are about priority. A real-time system, hard or soft, will run real-time application without context switches until that process is complete. No system would ever run a payroll system without context switches, it just doesn't make sense to do so.

  12. Problems vs. Systems by MarkusQ · · Score: 2

    You seem to be missing the underlying definition of a real-time system...a payroll system that runs on a real-time operating system...would pretty much mean that the only thing that operating system is used for is payroll.

    Real-time systems are about priority. A real-time system, hard or soft, will run real-time application without context switches until that process is complete.

    Real time problems are problems whose definition includes dependencies on the passage of real time.

    Real time systems systems that are used to solve real time problems.

    Prohibiting context switches is common in real time systems, since it eliminates one potential source of failures, but it isn't essential (you can get the same results by having a much faster processor, or a pool of processors, etc.) and in any case it isn't a cure-all. If the time constraints are tight enough that your hardware can't meet them, you're still out of luck.

    Claiming that payroll isn't a real time problem because you don't need a real time system that eschews context switches to solve it is the same sort of logic as claiming the earth isn't a planet because you don't need some specfic type of telescope to study its surface.

    -- MarkusQ