Announcement

Collapse
No announcement yet.

Thermal Pressure On Tap For Linux 5.7 So The Scheduler Can Be Aware Of Overheating CPUs

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

  • Thermal Pressure On Tap For Linux 5.7 So The Scheduler Can Be Aware Of Overheating CPUs

    Phoronix: Thermal Pressure On Tap For Linux 5.7 So The Scheduler Can Be Aware Of Overheating CPUs

    Going back about two years has been work by Linaro on "thermal pressure" support for the scheduler so that it can make better task placement decisions among CPU cores when any of the core(s) are being restricted by running too hot. That work is now set to finally land this spring with the Linux 5.7 kernel...

    http://www.phoronix.com/scan.php?pag...ermal-Pressure

  • #2
    I'm doubting the benefits of this. Sounds rather obvious, but cores sit very tight in the core complex of a SoC.
    If you're running one core hot, chances are you are going to run any core hot.
    We are not talking about different classes of cores in big.little configurations.

    Say you can squeeze out a few more percent by cycling through cores as they cool for a single task load.
    Then you're adding to the thermal runaway situation that caused the throttling as you load up the cores.
    Maximum usage without throttling >= power consumption which brings you closer to throttling either way.
    And if you're already loading the cores to full tilt, there is not much you can do.

    Anyone with some wise insights into this rather complex problem?

    Comment


    • #3
      Originally posted by milkylainen View Post
      I'm doubting the benefits of this. Sounds rather obvious, but cores sit very tight in the core complex of a SoC.
      If you're running one core hot, chances are you are going to run any core hot.
      We are not talking about different classes of cores in big.little configurations.

      Say you can squeeze out a few more percent by cycling through cores as they cool for a single task load.
      Then you're adding to the thermal runaway situation that caused the throttling as you load up the cores.
      Maximum usage without throttling >= power consumption which brings you closer to throttling either way.
      And if you're already loading the cores to full tilt, there is not much you can do.
      Even in big.LITTLE Setups, but there you have a greater chance to have small differences..

      But there are corner cases too,
      If you are not in the same L2 cache, loading the process to another core( not in same cluster ), could cost you more..
      Imagine a bit.LITTLE setup, which usually have l2 caches separated.., always jumping between big and LITTLE cores,
      Could have impact in performance too..

      Comment


      • #4



        Nevermind its mainly for ARM. Yeah I can see why this is needed.
        Last edited by creative; 03-07-2020, 11:06 PM.

        Comment


        • #5
          I would imagine the larger chips like Epyc that are made of multiple dies could see a nice improvement from this.

          Comment


          • #6
            Originally posted by milkylainen View Post
            I'm doubting the benefits of this. Sounds rather obvious, but cores sit very tight in the core complex of a SoC.
            If you're running one core hot, chances are you are going to run any core hot.
            We are not talking about different classes of cores in big.little configurations.

            Say you can squeeze out a few more percent by cycling through cores as they cool for a single task load.
            Then you're adding to the thermal runaway situation that caused the throttling as you load up the cores.
            Maximum usage without throttling >= power consumption which brings you closer to throttling either way.
            And if you're already loading the cores to full tilt, there is not much you can do.

            Anyone with some wise insights into this rather complex problem?
            Actually, in the world of MCM chips (AKA chiplets), you can have considerably different temperature between each cluster, especially given the fact that 64 core Eypc process has eight of them spread across a fairly large surface...

            - Gilboa
            DEV: Intel S2600C0, 2xE5-2658V2, 32GB, 6x2TB, GTX1080, F32, Dell UP3216Q 4K.
            SRV: Intel S2400GP2, 2xE5-2448L, 96GB, 6x2TB, GTX550, F32, Dell U2711.
            WIN: Gigabyte B85M-HD3, E3-1245V3, 32GB, 5x1TB, GTX980, Win10Pro.
            BAK: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F32.
            LAP: ASUS Strix GL502V, i7-6700HQ, 32GB, 1TB+256GB, 1070M, F31.

            Comment


            • #7
              Originally posted by gilboa View Post

              Actually, in the world of MCM chips (AKA chiplets), you can have considerably different temperature between each cluster, especially given the fact that 64 core Eypc process has eight of them spread across a fairly large surface...

              - Gilboa
              Yes. Obviously. But this article is about ARM and what is likely to be tight core packaging.
              I fail to see the major point f.ex. a cellphone big.little config.
              Sockets, or even chiplets, which house symmetrical units are likely to gain even more from this than SoCs.

              "The Linux thermal pressure code is designed with ARM SoCs in mind for better performance".

              Comment


              • #8
                Originally posted by milkylainen View Post
                Sockets, or even chiplets, which house symmetrical units are likely to gain even more from this than SoCs.

                "The Linux thermal pressure code is designed with ARM SoCs in mind for better performance".
                well,
                Multi-node systems would gain indeed, but there are also corner cases as those systems are majority NUMA systems..
                Which means, the memory latency is big when passing from one node to another..

                So, if you have a process running in a node, it would mean( in principle ), that the memory was allocated in that node memory region..
                Jumping from 1 node to another, would have a big cost on memory..

                So the scheduler needs also to be aware of that..

                Comment


                • #9
                  Originally posted by torsionbar28 View Post
                  I would imagine the larger chips like Epyc that are made of multiple dies could see a nice improvement from this.
                  It's actually the chips that are NOT on multiple dies that will see most improvements from this

                  Comment


                  • #10
                    Originally posted by milkylainen View Post
                    I'm doubting the benefits of this. Sounds rather obvious, but cores sit very tight in the core complex of a SoC.
                    If you're running one core hot, chances are you are going to run any core hot.
                    Not really, the issue is hot spots here. Cores generate too much heat for their tiny surface to move it away so you have a spike in temperature in that core and then it throttles. This happens before the heat even travels to neighboring cores.

                    Comment

                    Working...
                    X