Announcement

Collapse
No announcement yet.

The PREEMPT_RT Locking Code Is Merged For Linux 5.15

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

  • #11
    Originally posted by sinepgib View Post

    Take with a grain of salt, but essentially when you use real time you trade off throughput for responsiveness. You have deadlines to fulfill so you limit how much time a given task can take at the cost of interrupting tasks more often, which adds overhead and limits how much individual processes can do in a given time slice. That's why it may be good for audio and gaming, as it will reduce skipped frames because some process took too much time before giving a slot back to your game, but compute intensive tasks will take longer to complete.
    Yeah, but I was wondering if you could get the best of both of worlds.
    So when you run a application that uses RT then the kernel runs with more responsiveness and less throughput, but when you're not running any applications that make use of RT then the kernel runs with fast throughput as normal without the overhead of RT.

    Comment


    • #12

      Originally posted by sinepgib View Post

      Take with a grain of salt, but essentially when you use real time you trade off throughput for responsiveness. You have deadlines to fulfill so you limit how much time a given task can take at the cost of interrupting tasks more often, which adds overhead and limits how much individual processes can do in a given time slice. That's why it may be good for audio and gaming, as it will reduce skipped frames because some process took too much time before giving a slot back to your game, but compute intensive tasks will take longer to complete.
      Was going to say the exact same thing but then I noticed your post


      Originally posted by uid313 View Post

      Yeah, but I was wondering if you could get the best of both of worlds.
      So when you run a application that uses RT then the kernel runs with more responsiveness and less throughput, but when you're not running any applications that make use of RT then the kernel runs with fast throughput as normal without the overhead of RT.
      Kinda, sorta, not really. Doing so becomes incredibly complex and typically it may not be possible unless userspace applications/processes can give hints to the OS scheduler whether they care about raw throughput or they care about performance.

      This same issue occurs in backend web services, were you can use different design patterns to trade throughput for latency (specifically having a more stable but slightly higher average latency using work stealing algorithms).

      To do this stuff properly you would need a formally verified kernel which is built around the concept of RT that can provide guarantees about processes and Linux is not one of those. Unfortunately historically LInux has been more of a server system than a desktop where throughput had higher priority.

      Comment


      • #13
        Originally posted by kbios View Post

        Well, for me using the RT kernel is the difference between having or not having xruns in jackd, so it does have an impact
        yeah right, you clearly don't know what you are talking about.. maybe you can start by understanding the difference between soft RT and hard RT. As I said before, Linux has had soft RT for quite some time, and all the audio processing software is using it. Hard RT is something different, and and usually needed let say to control CNC machines and anything that needs hard latency guarantees in the microseconds range.

        The patchset in the article is about hard RT.

        Comment


        • #14
          Originally posted by zaro View Post

          yeah right, you clearly don't know what you are talking about.. maybe you can start by understanding the difference between soft RT and hard RT.
          That makes two of you then, audio is a hard real time problem.

          Comment


          • #15
            Originally posted by uid313 View Post

            Yeah, but I was wondering if you could get the best of both of worlds.
            So when you run a application that uses RT then the kernel runs with more responsiveness and less throughput, but when you're not running any applications that make use of RT then the kernel runs with fast throughput as normal without the overhead of RT.
            Some kind of coexistence might be possible in theory, but in practice, no. Most of the overhead of RT is because it modifies many of the core concurrency primitives in the kernel in order to provide determinism.

            I guess in principle you could "split" the kernel, with RT tasks on dedicated cores, and non-RT tasks on separate cores, and taking great care with any communication between the two domains. In practice, nope. If you want something like this you might as well use VM's or some hardware-assisted partitioning in order to run two separate kernels.

            Comment


            • #16
              Originally posted by zaro View Post

              yeah right, you clearly don't know what you are talking about.. maybe you can start by understanding the difference between soft RT and hard RT. As I said before, Linux has had soft RT for quite some time, and all the audio processing software is using it. Hard RT is something different, and and usually needed let say to control CNC machines and anything that needs hard latency guarantees in the microseconds range.

              The patchset in the article is about hard RT.
              Ideally, you'd have hard RT in a studio for recording/mixing high-$ musicians or for electronic instruments... Same reason why we are increasingly seeing Ethernet AVB (TSN) in studios instead of layers on top of (standard, non-realtime) Ethernet.
              Of course, you also want hard RT for control tasks including CNC, drones, cars, etc.

              Comment


              • #17
                Originally posted by caligula View Post
                The RT stuff is really only useful to those who have a DAW
                it's still nice to be able to run daw on non-patched kernel

                Comment


                • #18
                  Originally posted by jabl View Post
                  Some kind of coexistence might be possible in theory, but in practice, no. Most of the overhead of RT is because it modifies many of the core concurrency primitives in the kernel in order to provide determinism.

                  I guess in principle you could "split" the kernel, with RT tasks on dedicated cores, and non-RT tasks on separate cores, and taking great care with any communication between the two domains. In practice, nope. If you want something like this you might as well use VM's or some hardware-assisted partitioning in order to run two separate kernels.
                  This is a widely used concept in RTOS - I/O is usually the limiting factor (VM or not).

                  Comment


                  • #19
                    Originally posted by uid313 View Post
                    Yeah, but I was wondering if you could get the best of both of worlds.
                    I like how almost everyone [You're explicitly excluded perpetually high] in this thread likes to respond in theoretical terms (which usually means talking out of their collective a$$es) without contributing any helpful advice or hint in the end anyway; most likely because they never have used a hard-RT Linux kernel in the first place!

                    So let me change that for you:

                    AFAIK, you are running Ubuntu LTS or a derivative distro based on it, right?
                    Great, this is the very foundation for the absolute best Linux user experience and I applaud you for this correct decision!

                    Now, all you have to do is to install the so-called »lowlatency« kernel officially supported by Canonical and get rid of the "generic" one.
                    This will net you a 1000 Hz + fully-preemptible soft-RT LInux kernel, which basically means that you get most of the benefits of a hard-RT kernel minus the drawbacks like severely degraded performance.
                    [For anyone doubting the degraded performance part: Just compare with advanced software like RPCS3 & and watch your FPS plummet hard with a hard-RT kernel.]

                    BTW, this is the very same kernel configuration that Google uses across Android + ChromeOS + Stadia.
                    If hard-RT really would've been a "magic bullet", then why isn't it used everywhere?
                    Wouldn't Google want their Android OS to perform better than Apple's iOS?
                    And how come Valve isn't going to ship their upcoming Steam Deck with a hard-RT kernel?
                    Are all of these corporations & their employees really that dumb?

                    Point is, hard-RT Linux has its places & use-cases, and I'm glad that it's getting upstreamed so that more companies & individuals can pick up on it more easily where safety is the top-priority.
                    However, for the average desktop Linux user, I fear this will give them a false sense of having a superior kernel at their disposal, when in fact the opposite will be true.

                    Therefore, with a 1000 Hz + PREEMPT kernel, you already do get the best of both worlds!

                    Comment


                    • #20
                      Originally posted by Linuxxx View Post
                      AFAIK, you are running Ubuntu LTS or a derivative distro based on it, right?
                      Great, this is the very foundation for the absolute best Linux user experience and I applaud you for this correct decision!
                      Now, all you have to do is to install the so-called »lowlatency« kernel officially supported by Canonical and get rid of the "generic" one.
                      The RT kernel is packaged in debian, not ubuntu.

                      Originally posted by Linuxxx View Post
                      This will net you a 1000 Hz + fully-preemptible soft-RT LInux kernel, which basically means that you get most of the benefits of a hard-RT kernel minus the drawbacks like severely degraded performance.
                      "Fully preemptible" and "soft RT" are mutually exclusive
                      Soft RT gives you low latency, usually
                      Hard RT gives you latency guarantees, always

                      Repeat after me: "You want to the steering of your car, which increasingly uses Linux, to (placeholder) work". Now substitute (placeholder) with "usually" or "always". Do you have a preference?

                      Originally posted by Linuxxx View Post
                      [For anyone doubting the degraded performance part: Just compare with advanced software like RPCS3 & and watch your FPS plummet hard with a hard-RT kernel.]
                      Who invited the gamer to the control thread?

                      Originally posted by Linuxxx View Post
                      BTW, this is the very same kernel configuration that Google uses across Android + ChromeOS + Stadia.
                      If hard-RT really would've been a "magic bullet", then why isn't it used everywhere?
                      Wouldn't Google want their Android OS to perform better than Apple's iOS?
                      And how come Valve isn't going to ship their upcoming Steam Deck with a hard-RT kernel?
                      Are all of these corporations & their employees really that dumb?
                      You are missing the point entirely. This is for companies like Siemens, Tesla, or Boeing. Definitely not Google.

                      Originally posted by Linuxxx View Post
                      Point is, hard-RT Linux has its places & use-cases, and I'm glad that it's getting upstreamed so that more companies & individuals can pick up on it more easily where safety is the top-priority.
                      Ok we are getting somewhere...

                      Originally posted by Linuxxx View Post
                      However, for the average desktop Linux user, I fear this will give them a false sense of having a superior kernel at their disposal, when in fact the opposite will be true.
                      ... or maybe not.

                      Besides the jokes. You still need to enable hard realtime and you can also disable it.

                      Originally posted by Linuxxx View Post
                      Therefore, with a 1000 Hz + PREEMPT kernel, you already do get the best of both worlds!
                      For you, maybe. For applications where hard RT is required, this is not sufficient - by a long shot.
                      Last edited by mppix; 31 August 2021, 11:27 PM.

                      Comment

                      Working...
                      X