Announcement

Collapse
No announcement yet.

RT Patches Updated For Linux 5.19-rc1 - Real-Time Inches Closer To The Finish Line

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RT Patches Updated For Linux 5.19-rc1 - Real-Time Inches Closer To The Finish Line

    Phoronix: RT Patches Updated For Linux 5.19-rc1 - Real-Time Inches Closer To The Finish Line

    The real-time (RT) patch series still hasn't been mainlined but the patch delta is slowly winding down with each new kernel version. Out today is the re-based RT patch series for the recently minted Linux 5.19-rc1 with some of the prior real-time patches having been upstreamed this merge window and other patches re-based to work with the newest kernel code...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Wow, you mean the Linux kernel will be real-time soon? I wasn't even aware they were working towards this.
    Is this hard real time?

    Comment


    • #3
      Originally posted by bug77 View Post
      Wow, you mean the Linux kernel will be real-time soon? I wasn't even aware they were working towards this.
      Is this hard real time?
      If you want the strict definition of hard real-time, which requires having a proven mathematical model, then no. In real usage scenarios, it wasn't shown to fail, provided everything is setup correctly. You can consider it at the least to be "firm real time".

      This patch existed for quite a while (years) but outside the kernel tree as the article states.
      Last edited by abu_shawarib; 07 June 2022, 07:55 PM.

      Comment


      • #4
        Originally posted by bug77 View Post
        Wow, you mean the Linux kernel will be real-time soon? I wasn't even aware they were working towards this.
        Is this hard real time?
        i am sure it is not "hard real time" last time i checked into this topic is that hard real time is impossible and i really mean impossible
        but luckily modern real time does not need to be hard real time.

        there are some science studies about the linux kernel realtime builds and they try to disprove the real time functionality over a longer of time with millions of try to get anything out of step and they where all not able to do so.

        the different from hard real time like microsoft DOS run a single task on a singlecore cpu who run a spezific task at a spezific clock step of the cpu this "Soft real time" of the linux kernel has a Scheduler who makes sure a spezific timeframe is not left for a spezific task.

        with this: "microsoft DOS run a single task on a singlecore cpu who run a spezific task at a spezific clock" you can say exactly at what time and clock of the cpu does have a spezific status at a spezific clock/time... thats calles hard real time...
        no one does this anymore today because the performance you get with this is poor and it is only singlecore...

        Linux is not this kind of hard real time... but on the other side you can not proof statistically that real time linux kernel hurts any given time-frame...


        "Linux provides both user preemption as well as full kernel preemption.[163] Preemption reduces latency, increases responsiveness,[164] and makes Linux more suitable for desktop and real-time applications.

        For normal tasks, by default, the kernel uses the Completely Fair Scheduler (CFS) class, introduced in the 2.6.23 version of the kernel.[82] Internally this default-scheduler class is defined in a macro of a C header as SCHED_NORMAL. In other POSIX kernels, a similar policy known as SCHED_OTHER allocates CPU timeslices (i.e, it assigns absolute slices of the processor time depending on either predetermined or dynamically computed priority of each process). The Linux CFS does away with absolute timeslices and assigns a fair proportion of CPU time, as a function of parameters like the total number of runnable processes and the time they have already run; this function also takes into account a kind of weight that depends on their relative priorities (nice values).[165]

        With user preemption, the kernel scheduler can replace the current process with the execution of a context switch to a different one that therefore acquires the computing resources for running (CPU, memory, and more). It makes it according to the CFS algorithm (in particular, it uses a variable called vruntime for sorting entities and then chooses the one that has the smaller vruntime, - i.e., the schedulable entity that has had the least share of CPU time), to the active scheduler policy and to the relative priorities.[166] With kernel preemption, the kernel can preempt itself when an interrupt handler returns, when kernel tasks block, and whenever a subsystem explicitly calls the schedule() function.

        The kernel also contains two POSIX-compliant[167] real-time scheduling classes named SCHED_FIFO (realtime first-in-first-out) and SCHED_RR (realtime round-robin), both of which take precedence over the default class.[160] An additional scheduling policy known as SCHED DEADLINE, implementing the earliest deadline first algorithm (EDF), was added in kernel version 3.14, released on 30 March 2014.[168][169] SCHED_DEADLINE takes precedence over all the other scheduling classes.

        Real-time PREEMPT_RT patches, included into the mainline Linux since version 2.6, provide a deterministic scheduler, the removal of preemption and interrupts disabling (where possible), PI Mutexes (i.e., locking primitives that avoid priority inversion),[170][171] support for high precision event timers (HPET), preemptive Read-copy-update, (forced) IRQ threads, and other minor features.[172][173][174]
        "
        Phantom circuit Sequence Reducer Dyslexia

        Comment


        • #5
          Originally posted by abu_shawarib View Post
          If you want the strict definition of hard real-time, which requires having a proven mathematical model, then no. In real usage scenarios, it wasn't shown to fail, provided everything is setup correctly. You can consider it at the least to be "firm real time".
          Thank you, that makes sense. So, no go for nuclear power plants, I guess, but easier to get there if someone needs to.
          Originally posted by abu_shawarib View Post
          This patch existed for quite a while (years) but outside the kernel tree as the article states.
          I knew about the patches, I was just completely unaware there was ongoing effort to mainline things.

          Comment


          • #6
            Can anyone contact Intel if there's real interest in putting more efforts to finally upstream it and such?

            What about AMD? What about ARM? What about Nvidia? What about others?

            Comment


            • #7
              Originally posted by timofonic View Post
              Can anyone contact Intel if there's real interest in putting more efforts to finally upstream it and such?

              What about AMD? What about ARM? What about Nvidia? What about others?
              Looking at the patches (linked below), it contains patches for arm, aarch64, powerpc, x86.

              Comment


              • #8
                Considering who has to merge it at last, shouldn't that be "the Finnish line"?

                Comment


                • #9
                  @Michael

                  Can you ask them about their linux rt strategy? Please! I'm highly interested and consider it even a highly underrated project.

                  Comment

                  Working...
                  X