Announcement

Collapse
No announcement yet.

Linux 5.5's Scheduler Sees A Load Balancing Rework For Better Perf But Risks Regressions

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

  • Linux 5.5's Scheduler Sees A Load Balancing Rework For Better Perf But Risks Regressions

    Phoronix: Linux 5.5's Scheduler Sees A Load Balancing Rework For Better Perf But Risks Regressions

    Ingo Molnar sent in the kernel's scheduler changes along with the other material he is overseeing for Linux 5.5. With this next version of the Linux kernel comes a rework to the Completely Fair Scheduler's load balancing logic. This is helping some workloads at least but with the intrusive change runs the risk of possible regressions...

    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
    Next goal: Merge Linux-RT.

    Comment


    • #3
      Originally posted by timofonic View Post
      Next goal: Merge Linux-RT.
      İmmensely more interesting & meaningful for us mere peasant desktop users:

      Which scheduler were they using when coming up with these improved numbers?
      "SchedUtil"?
      İf so, will it ever be able to consistently dethrone the 'performance' governor?

      ​​​​​​​And what about AMD RyZen owners (heard there are already a few of them), who right now still don't have anything comparable to İntel's "P-State" driver (where incidentally 'schedutil' isn't even an option by default) and who will probably end up with having no other choice than to use the "schedutil" CPU governor, since this has already been clearly communicated by the relevant upstream developers as the way forward for the Linux kernel (well, at least when it comes to AMD & ARM)!

      Comment


      • #4
        Originally posted by Linuxxx View Post

        İmmensely more interesting & meaningful for us mere peasant desktop users:

        Which scheduler were they using when coming up with these improved numbers?
        "SchedUtil"?
        İf so, will it ever be able to consistently dethrone the 'performance' governor?

        ​​​​​​​And what about AMD RyZen owners (heard there are already a few of them), who right now still don't have anything comparable to İntel's "P-State" driver (where incidentally 'schedutil' isn't even an option by default) and who will probably end up with having no other choice than to use the "schedutil" CPU governor, since this has already been clearly communicated by the relevant upstream developers as the way forward for the Linux kernel (well, at least when it comes to AMD & ARM)!
        Don't get me wrong, it seems you're confusing CPU governors with schedulers.

        They are related, but different.

        Real-time is very interesting, far more than it seems.

        Comment


        • #5
          What they really should do is non fair scheduling and slow down processes causing a lot of IO Wait. Like when you use qgit to view the linux repo and run out memory because chrome has too many tabs open. And the whole machine stops to a grinding halt and you can't even move you mouse to kill it.

          Talking of a DoS vulnarability...

          Comment


          • #6
            Originally posted by ferry View Post
            What they really should do is non fair scheduling and slow down processes causing a lot of IO Wait. Like when you use qgit to view the linux repo and run out memory because chrome has too many tabs open. And the whole machine stops to a grinding halt and you can't even move you mouse to kill it.

            Talking of a DoS vulnarability...
            This thread is about CPU scheduler and your advice is related to I/O one. It probably has nothing to do with being fair or at least trying.

            Comment


            • #7
              Originally posted by Volta View Post

              This thread is about CPU scheduler and your advice is related to I/O one. It probably has nothing to do with being fair or at least trying.
              Yes, that's the problem. A process doing that much io or using that much memory that swapping starts hurting other processes or even the kernel itself should receive less cpu time.

              Comment


              • #8
                Originally posted by ferry View Post

                Yes, that's the problem. A process doing that much io or using that much memory that swapping starts hurting other processes or even the kernel itself should receive less cpu time.
                It would be handy to have possibility to tune that.

                Comment

                Working...
                X