hoakley January 7, 2022 Macs, Technology

How macOS controls performance: QoS on Intel and M1 processors

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.

Appendix: Results

iMac Pro
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

16Comments

Add yours

1

Nick on January 7, 2022 at 10:41 am

It would be fascinating to see how macOS assigns QoS to its internal tasks. I assume that Apple will have done a lot of profiling to ensure that QoS is assigned in the best balanced way across the OS internal functions, but might this be an area they could further tweak in the future to improve energy efficiency?

Unless every OS function has simply been assigned a QoS of 9 so that all operations are already run as much by the E cores as possible?

LikeLiked by 1 person
- 2
  
  hoakley on January 7, 2022 at 3:29 pm
  
  Thank you. This is exactly what I am currently trying to do, at least on M1 Macs. As the QoS isn’t something normally exposed to the user, the best way to discover it is by watching what gets scheduled on the E cores.
  Although there are still loads which seem to spill over to P cores, almost everything run by macOS in the background appears to run almost exclusively on the E cores – from MRT scans to Time Machine backups. I think the strategy is to run those efficiently, and at reasonable times, as precise timing isn’t that important. If two background processes occur at the same time, it’s no big deal to hold one of them back for a minute or two.
  This then keeps the P cores essentially free for user processes. As they’re time-critical and the response is so important, they happen immediately, with the full power of all the P cores.
  Because this is all implemented in software, it’s easy for Apple to change should it ever wish, or even to use adaptive algorithms.
  Howard.
  
  LikeLike
3

Michael Bach on January 7, 2022 at 10:53 am

Thank, I read your E vs. P cores adventures with great interest.
I wonder about one thing though: Assume (briefly) everything were linear. Then an E core uses less battery, but also takes longer, thus creating the same net _energy_ demand as a P core for the same task. So where’s the advantage of having E & P?
Ok, so not everything is linear. Assuming (because of stray capacitors etc.) the power demand rises faster than clock speed, there is an E advantage. But assuming a task should be done by some specific time, the E is at disadvantage again because there is always some base power demand, which makes E effectively less efficient as it takes longer.
So a real quantitative advantage of E for background tasks depends on the relative quantitative merits of non-linearity at the high-speed and, and base rate at the low speed end.
Am I making myself clear? 🙂

LikeLiked by 1 person
- 4
  
  hoakley on January 7, 2022 at 3:32 pm
  
  Thank you – yes. And that’s very task-dependent. In my previous look at CPU-intensive tight loops which don’t access memory, the benefits are very clear: “The two E cores in an M1 Pro, when at 100% active residency and maximum frequency can outperform a single P core at 100% active residency and maximum frequency, while using one fifth of the power.”
  The general picture of the E cores is that they are far more efficient in that sense, and do produce very large savings in energy.
  Howard.
  
  LikeLike
5

Ed on January 7, 2022 at 11:07 am

I never programmed in Swift but here’s how to set QoS in C if you want to try it out yourself. At the top use this include which should fetch it from the MacOSX.sdk subdirectory inside the Xcode application folder:

#include <pthread/qos.h>

And right at the top of main(), something like this where you use either the QOS_CLASS_BACKGROUND (=9) or the QOS_CLASS_USER_INTERACTIVE (=33) constant:

// int e = pthread_set_qos_class_self_np(QOS_CLASS_BACKGROUND, 0); int e = pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0); if (e) { fprintf(stderr, "Pthread error: %d\n", e); exit(1); }

User programs should be in the “User Interactive” class by default but this makes it explicit. I don’t think intermediate values are useful for now, they will probably all round up to User Interactive.

LikeLiked by 1 person
- 6
  
  Ed on January 7, 2022 at 11:09 am
  
  Argh, the code tags do work but don’t encode brackets. Sorry. That include should have read: #include <pthread/qos.h>
  
  LikeLiked by 1 person
  - 7
    
    hoakley on January 7, 2022 at 3:36 pm
    
    I have corrected your original – it’s because you have to use escape codes for < and > in WordPress.
    Howard.
    
    LikeLike
- 8
  
  hoakley on January 7, 2022 at 3:35 pm
  
  Thank you – that’s valuable.
  I haven’t yet looked too hard at the two intermediate QoS, but what I have seen so far appears identical to high QoS (33). Those lower values could perhaps affect priority of scheduling, which is harder to see.
  Howard.
  
  LikeLiked by 1 person
  - 9
    
    Ed on January 8, 2022 at 9:26 am
    
    Thanks, yes, I had done about the same: initially confirm that on a quiet system the intermediate values seem to work the same as high QoS. But no in-depth research, so I can’t be sure about the details. Also haven’t tried comparing M1 and Intel, this was just M1.
    
    LikeLiked by 1 person
    - 10
      
      hoakley on January 8, 2022 at 8:06 pm
      
      Thank you.
      Howard.
      
      LikeLike
11

winmaciek on January 7, 2022 at 4:37 pm

I wonder if QoS is taken into account when running the Mac in low or high power mode. In the first case this would mean that a task that is normally performed using performance cores is pushed onto the efficiency ones, in the latter one the processes would be more likely to be performed using the high power cores. I have no idea if that’s the case though.

LikeLiked by 1 person
- 12
  
  hoakley on January 7, 2022 at 5:19 pm
  
  Thank you. Although I haven’t made extensive studies, I can answer that for Low Power Mode. Low QoS processes don’t appear to be affected by that, and still run on the E cores with similar performance. However, high QoS processes, which continue to use the P cores, have a slightly reduced performance, as the P core maximum frequency is held at slightly less than 90% of normal.
  I don’t think that High Power Mode affects the cores at all: I think that is mostly concerned with derestricting the GPUs, but don’t have an M1 Max to test that on.
  Howard.
  
  LikeLike
13

jimgbuffalo on January 8, 2022 at 6:57 am

This may be daft, but I got to thinking about the possibility of a developer unnecessarily elevating QoS processes to a P core simply to claim that his or her software is “faster”. Or is the distribution of tasks between the P & E cores something the OS would ordinarily negotiate automatically?

LikeLiked by 1 person
- 14
  
  hoakley on January 8, 2022 at 7:29 am
  
  That’s not daft at all: that’s pretty well universal in third-party software. It should be fairly easy to tell, because anyone designing in sensible use of QoS for background processes should give the user the option. As so few products do that, I think it’s reasonable to assume that almost every app etc. runs their processes at default higher QoS, and none appears to make much if any use of the E cores. One exception that I have seen is Carbon Copy Cloner, but that still defaults to high QoS until you change it. I’ve also added choice to a couple of my apps, including my compression-decompression utility Cormorant.
  macOS can only obey the QoS which is set. It can’t try making decisions on its own. So when you watch what happens on an M1, you’ll see macOS itself primarily using the E cores, and apps etc. using the P cores.
  What developers and users need to accept is that it’s better for all if apps are wiser in their choice of QoS. This has large potential benefits when running on a notebook on battery too.
  I’m sure it will come in time.
  Howard.
  
  LikeLike
15

Dan Buettner on January 26, 2022 at 10:48 pm

Really appreciate your M1 Mac info. I’ve been struggling to utilize my performance cores properly doing Ruby on Rails development, running my test suite specifically. Is there a way to run a command line (terminal) process with a specific QoS set? Ideally I’d like to run my test suite as fast as possible, even if that means my apps stutter a bit. Thanks!

LikeLiked by 1 person
- 16
  
  hoakley on January 26, 2022 at 11:35 pm
  
  First, I’m not sure that QoS will help Ruby.
  You need more insight into how your Ruby code is being run. Is it interpreted? If so, does that limit it to run on just a single core?
  Next, open Activity Monitor and its CPU History window, and run your test suite. What pattern do you see (when the Mac is otherwise lightly loaded)? Is it running on a single core alone? E or P core(s)?
  If it’s limited to running on one core, as some interpreted languages are, and is already running on a P core, then the only other thing to check is the cluster frequency, which is available from the powermetrics command – search here on that as the term, and you’ll see how to use it.
  If it’s running on P core(s) at a frequency of 3000 MHz or more, then that’s as fast as it will go without using more cores or improving the interpreter/runtime efficiency.
  The straightforward way of running a command line process at a set QoS is to do so from within compiled code, which can create the thread in a queue with the set QoS. It’s not hard to code, but neither is it straightforward!
  Howard.
  
  LikeLike