Feature #17566: Tune thread QoS / efficiency on macOS

• Status: Open
• Assignee: -
• Target version: -

[mperham (Mike Perham)]

Hi, new Apple M1 processors have "performance" and "efficiency" cores. Apple provides a QoS API so threads can tune which cores they should execute on. Some threads should be executed as high-priority, some should be treated as low-priority.

This page shows the pthread APIs that Apple provides:

https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/PrioritizeWorkAtTheTaskLevel.html

pthread_set_qos_class_self_np(QOS_CLASS_BACKGROUND, 0)

I noticed Ruby already provides Thread#priority= which says This is just hint for Ruby thread scheduler. It may be ignored on some platform. Does this API work still or was it only active for Ruby 1.8's green threads? Should this API use the QoS APIs on macOS?

[ko1 (Koichi Sasada)]

Actually, Thread#priority is not tested.
I'm not sure we can use this pthread_set_qos_class_self_np API for priority because it accepts an integer and there is no agreement which number is "high" and "low". Introducing another API makes sense more for me. But I'm also not sure we can introduce a new API only for Mac OS.

Also I'm not sure pthread_set_qos_class_self_np is needed for Ruby users (I think Mac OS will choose good core than a programmer, I guess).

[shan (Shannon Skipper)]

From Apple's perspective, it's our "obligation" as developers to make apps go "absolutely idle" on performance cores when "not responding to user input." From their docs, it seems they hope for us to use fine grained priority when we can. See https://developer.apple.com/news/?id=vk3m204o

Apple silicon is so popular with programmers that I wonder if it's worth supporting QoS for the sake of developer tools written in Ruby?