Arm based Mac systems have several types of cores: performance cores and efficiency cores.  The system has no way to directly specify which core a particular proces or thread uses, but programs can use an API for setting the QOS class of a thread that will influence which type of core a proces is scheduled on.

The primary use case for this would be to select a lower QOS class for background tasks to ensure that those minimally impact interactive code.

It would be nice to expose this functionality in Python.


One way to do this is to expose two or three new APIs:

0. Expose an enum.IntEnum on macOS for the various QOS classes

1. An API for setting the QOS class of a particular thread (which could also be used to change that class for the main thread), for example a read/write property ``threading.Thread.qos_class``

2. A new keyword argument ``qos_class`` to ``threading.Thread.__init__()``

3. Optional: an API for setting changing the default value for that new keyword argument

The new API would only exist on macOS.

One consideration: This is a platform specific option, in my limited research I haven't found an easy way to accomplish similar results on Linux or Windows.

Background information: https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon

I am +1 on with supporting a way to select QOS attribute but I would like to consider using a more seamless way :)

> but I would like to consider using a more seamless way 

For example, using a priority policy that actually uses QOS attribute :)

> For example, using a priority policy that actually uses QOS attribute :)

How would that look? 

The QOS class is already a high level interface that affects a number of low-level polices. The classes are comprehensively documented in sys/qos.h.

In short (my rephrasing and summary of the documentation in sys/qos.h):

* QOS_CLASS_INTERACTIVE

   This QOS class indicates that the work on the thread is interactive with the user.

  
* QOS_CLASS_USER_INITIATED

   This QOS class indicates that work was initiated by the user and the user is likely
   waiting for the result.

   
* QOS_CLASS_DEFAULT

   Default QOS class.

  
* QOS_CLASS_UTILITY

  This QOS class indicates that work may or may not be initiated by the user and the 
  user is unlikely to be waiting for the result.

* QOS_CLASS_BACKGROUND

   This QOS class indicates that the work on this thread was not initiated by the user,
   and the user is not waiting for a result.

Having a python policy object instead of these fixed classes might be more flexible, but tuning those is anything but trivial and exposing such a low-level interface directly to users would likely be too complex for most use cases.  I'd be more interested in trying to implement the same interface on other platforms using the low-level APIs for those platforms (but won't do that, all my linux code is running on servers and uses tooling enternal to the application to control resource usage).

The biggest problem with these predefined classes is that they are pretty much targeted toward end-user systems and not servers, but that's the target of macOS anyway. 

BTW. I'm working on a PR.

> I'd be more interested in trying to implement the same interface on other platforms using the low-level APIs for those platforms

Yeah, I am on the same line, I prefer to provide the interface that the user actually doesn't care about implementation detail.

But it looks hard to map to priority policy.
A similar discussion from the Ruby team:
https://bugs.ruby-lang.org/issues/17566

Definitely not an OS specific concept.  Big.little configs are all over the place on all OSes and architectures these days.  With a variety of ways OSes are experimenting with scheduling for them (nevermind that Android and iOS have been doing this for a decade).

from scheduling policies such as users, cgroup membership, container membership, group membership, nice level, to QoS attributes as you mention here...

If a given OS has specific APIs we should expose them via the os or _thread modules as appropriate.  But unless multiple OSes congeal around common concepts, there isn't much we can do for abstraction.  Perhaps a generic way to supply a generic OS specific settings instance to threading.Thread for implementation defined configuration purposes before Thread.start() is called.

I agree. I'm working on a PR to expose this platform specific functionality in the threading module. It would have been nice if other platforms had similar functionality, but they don't. 

Emulating the API is possible, but a project in its own right and something that will result in a lot of discussion. IMHO this is something we shouldn't do within the CPython project.