QOS_CLASS_USER_INITIATED: Still moves to the efficiency cores, but takes longer when minimized. Still migrates off to the efficiency cores after the screen has been locked for a while. QOS_CLASS_USER_INTERACTIVE: Hangs out on the performance cores for a while, including for a reasonable period of time (I got bored of waiting) when minimized. However, if you were on a laptop and really didn’t want your VM to impact battery life, this might be useful. QOS_CLASS_BACKGROUND: Runs purely on the efficiency cores. QOS_CLASS_UTILITY: Same general behavior as QOS_CLASS_USER_INITIATED, still moves to the efficiency cores. Remains on the performance cores for a short period with the screen locked, but still ends up on the efficiency cores after a while.

Remains on the performance cores far, far longer when minimized, but will still shuttle over to the efficiency cores at some point. QOS_CLASS_USER_INITIATED: Definite improvements. Still lives on performance cores when in the foreground and utility cores in the background. QOS_CLASS_USER_INTERACTIVE: No meaningful change from default behavior. I tried adding this the pthread_set_qos_class_self_np call to the start of qemu_thread_start in util/qemu_thread_posix.c - which is definitely getting called, and seems to be the only thing that pthread_create creates - which is how qemu, as I understand it, is creating threads. Is consistent with Apple’s scheduling guidelines, but I spent part of today messing with it, with the following results:

The magic code in that patch, pthread_attr_set_qos_class_np(&attr, QOS_CLASS_USER_INTERACTIVE, 0) Thanks - unfortunately, I’ve already tried that method, and it doesn’t work reliably.

Qemu on mac m1