If you’ve been following any of my articles about the performance of the cores in M1 series chips, you’ll have come across the term Quality of Service (QoS), which can have major impact on how fast code runs on processors under macOS. This article explains how it’s set and what its effects are.
Since 2006, Macs have all had at least two processor cores (some early Intel Mac minis only had one, though). One of the tasks of macOS has been to schedule processes to those cores. In addition to each process being given a priority, a number that can be changed using the command tool
renice, some years ago Apple introduced another setting, the QoS. This is set for each process, and can be one of four discrete values from 9 (the lowest, for background tasks) to 33 (the highest, for tasks involving user interaction).
QoS is a control set and changed in the code launching a process, and can only be altered by the user if the app exposes a control, a feature which remains exceptionally uncommon. Neither is there any easy way for a user to know the QoS of any given process unless the app reveals that.
So far, on Intel Macs at least, using the QoS hasn’t had a great deal of effect. To show what happens at the two extremes of QoS, I’ve run some compression and decompression tests using my app Cormorant, which relies on the AppleArchive library introduced in macOS 11. Each of the results that I show here is obtained from compressing and decompressing a 10 GB file at either the lowest QoS (9) or the highest (33).
On my iMac Pro at high QoS, compression ran at a rate of 1.38 GB/s. Dropping the QoS slowed it slightly to 1.04 GB/s, that’s 75% of the maximum speed, and still extremely quick. Decompression at high QoS was naturally quicker at 2.19 GB/s, and 80% of that speed at low QoS, at 1.76 GB/s.
Looking at Activity Monitor’s CPU History window, the differences aren’t that big either.
Those peaks show:
- compression, high QoS
- decompression, high QoS
- compression, low QoS
- decompression, low QoS.
This bears out my experience in using QoS on Intel Macs, that it doesn’t really change performance much. Perhaps if there was a lot of contention for cores, it would play a bigger role, but I try to avoid getting into those situations in the first place.
Until the end of last year, Intel processors came with the same cores, nothing like the Efficiency (E) and Performance (P) cores in Apple’s M1 chips. The latter are managed very differently, and it’s here that QoS becomes much more important.
On my M1 Pro MacBook Pro at high QoS, compression was significantly faster than the Intel iMac, at 1.73 GB/s. Dropping the QoS slowed the M1 much more, though, to 0.2 GB/s, that’s only 12% of the speed. Decompression at high QoS was blisteringly fast at 5.55 GB/s, which makes my 8-core iMac look old and quaint, but at low QoS slowed to 1.26 GB/s, 23% of the speed. Differences in performance which are subtle on Intel processors can become stark on an M1.
The reason for this is shown in the CPU History window.
I’ve labelled the peaks the same way here, and they show how running at high QoS uses all ten cores, but only the two E cores at the top for low QoS.
There’d be little point in having two different types of core in your Mac if their use wasn’t managed according to a cunning strategy. What macOS currently chooses to do is to run lowest QoS processes on the E cores alone (four in the original M1 chip, two in the M1 Pro and Max chips), so that the P cores remain available to run high QoS processes, such as user apps.
There are plenty of tasks, like backups and Spotlight indexing, which we don’t need to run as fast as possible, so long as they’re completed in a reasonable time, and don’t interfere with the apps we’re using.
What is a bit sad at the moment is how few apps appear to make full use of QoS as a control which can be set by the user. Carbon Copy Cloner appears to have been offering this for some time, but (other than some of my own apps) I haven’t come across any other software which gives us the option. If you’ve come across any, I’d be delighted to know of it, please.
But who in their right mind would ever opt to run even background processes more slowly? Anyone with an M1 MacBook Air or Pro is certainly a prime candidate, as putting background tasks on the E cores results in great economy of battery use. It’s possible, under the strategy used by macOS, for heavyweight tasks to use 20% of the power when run on the E rather than P cores. That isn’t going to be such a concern on your Mac mini or iMac, but could make a big difference to notebook users.
At the other extreme, power users who are putting their P cores to work hard for them should also welcome the chance to have macOS run as much as possible on the E cores in the background.
Currently, unless an app provides a control in its preferences somewhere which you can use to set the QoS of its background processes, you’re most unlikely to be offered any choice. What’s more, apps are unlikely to check whether they’re being run on battery alone and change QoS accordingly. What might be good would be for Apple to offer performance profiles, in which a lower QoS might be interpreted differently, perhaps. Then a process with a QoS of 17, which is next lowest, might be run on E cores alone when that Mac is running on battery alone, and so on.
For most of us the first hurdle is recognising that, even on an M1 Mac, both processor power and battery life are finite resources. Learning to make wise compromises leads to the best outcomes.
Compression took 7.22755 seconds at QoS 33 = 1.38 GB/s
Decompression took 4.57298 seconds at QoS 33 = 2.19 GB/s
Compression took 9.58666 seconds at QoS 9 = 1.04 GB/s = 75% of the speed at QoS 33
Decompression took 5.69551 seconds at QoS 9 = 1.76 GB/s = 80% of the speed at QoS 33
M1 Pro MBP
Compression took 5.77281 seconds at QoS 33 = 1.73 GB/s
Decompression took 1.80090 seconds at QoS 33 = 5.55 GB/s
Compression took 51.02745 seconds at QoS 9 = 0.20 GB/s = 12% of the speed at QoS 33
Decompression took 7.91521 seconds at QoS 9 = 1.26 GB/s = 23% of the speed at QoS 33