Announcement

Collapse
No announcement yet.

Linaro Revives "Thermal Pressure" Code For Better Performance When CPUs Running Hot

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

  • Linaro Revives "Thermal Pressure" Code For Better Performance When CPUs Running Hot

    Phoronix: Linaro Revives "Thermal Pressure" Code For Better Performance When CPUs Running Hot

    Back in October 2018 was a patch series out of Linaro for "thermal pressure" support in the Linux kernel for providing better task placement when CPUs are running hot/overheating to the extent their CPU frequencies are being downclocked/limited. Out this weekend is a revised version of that Linux thermal pressure support...

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

  • pegasus
    replied
    This looks very interesting for large compute farms as well. I wonder how it will end up integrated with cgroups ...

    Leave a comment:


  • sandy8925
    replied
    IMO it's better to address the actual problem of inadequate cooling, rather than try to work around them with software changes. Of course, this is most likely for those scenarios where end users are unable to improve the cooling situation (laptops, mobile phones and tablets, watches etc.)

    Leave a comment:


  • polarathene
    replied
    Originally posted by timofonic View Post
    Can this be useful for x86 laptops to avoid CPU throttling and have a more fluid experience?
    Presumably, since it seems to bias assignment away from cores with higher temperatures(but presumably not the coldest to favor frequency boost latency?), as thermal throttling is degrading performance. I guess that depends on if the other cores are able to run cooler(in Ryzen CPUs the boundary of dies and CCX groupings might work well to balance across those?).

    The article wasn't entirely clear about what was referred to as the scheduler. The CPU/task scheduler is what assigns tasks right, so this feature is meant to either be an improvement to the default CFS or provide hints in some way? Not clear if other schedulers like MuQSS or BMQ would benefit and be able to use it. MuQSS at least I think just bounces tasks/threads around cores anyway(you can configure to prefer using threads on same core with SMT rq_sharing, or CCX with MC rq_sharing I think).

    Both MuQSS and BMQ don't support cgroups(at least CPU related ones afaik are just stubs), which prevents a few useful features and tools/utilities from being compatible(but due to the stubs, they may assume cgroup support fully), such as PSI(memory pressure metrics), schedutil(I think uses cgroups too), BFQ-mq also uses cgroup(but not sure if CPU ones), CPU accounting(usage %) is another but not sure if that's cgroup related(it's often said to be inaccurate with MuQSS, at least without the highres timer ck patches, and cgroups that try to use portion of CPU time/limit via systemd or docker and the like apparently don't work). Really makes these alternative CPU schedulers less attractive if you'd like any of that to work, wouldn't be surprised if they're not able to benefit from this.

    Leave a comment:


  • timofonic
    replied
    Can this be useful for x86 laptops to avoid CPU throttling and have a more fluid experience?

    Leave a comment:

Working...
X