![]() ![]() Furthermore, running taskpolicy -B returns the high QoS threads to the P cores, but doesn’t affect low QoS threads. What it doesn’t do, though, is alter the order of completion of the threads, which are still run in the same sequence as determined by their original QoS. This successfully demotes all threads, from both queues, to run on the E cluster alone. Shown at the figure 2 is the effect of running taskpolicy -b on AsmAttic’s PID. Short peaks on both P clusters reflect those threads run from the high QoS queue, and a prolonged peak on the two E cores at the top results from the odd-numbered threads running on the E cluster. However, as expectedĬonfined all threads to the E cluster, as shown in the CPU History window, and confirmed using powermetrics.įirst run, marked by the figure 1, shows these tests being run without the use of taskpolicy. This shows a small demonstration, in which three QoS 33 threads, numbers 6, 4 and 2, completed at an elapsed time of less than 0.66 seconds, followed by QoS 9 threads 1, 3 and 5 after 1.7 and 3.6 seconds.Īgainst AsmAttic’s PID didn’t change results at all, with QoS 9 processes still running slower on the E cluster. With modest numbers of odd-numbered threads run at lowest QoS and even-numbered ones at highest QoS, all the high QoS threads, run on P cores, complete first, in roughly the same order that they are added to the queue. As you’d expect, threads are run in the order that they’re created, and after allowing for some to run more slowly when allocated to the E cluster, they normally complete in similar order, with batch effects.Īlternating test threads between different QoS changes this. It creates up to a hundred identical threads and adds those to that queue. Previously, AsmAttic ran one thread queue at a single user-selectable QoS. This is used by a new option to alternate test threads between those two extreme QoS values. To investigate this, I modified my AsmAttic test utility so that it can manage two thread queues, one at minimum QoS, the other at maximum. This implies that the effects of taskpolicy and setpriority() are the result not of changing QoS, but directly on which cores can be used. If a process is normally set to run at high QoS, so having access to both E and P cores, and it’s then demoted to run on E cores alone, it can be promoted back to have access to both core types again. What might at first appear more puzzling is that taskpolicy and setpriority() can repromote processes and threads which they have demoted. While setpriority() can be used to demote processes to use only E cores, it can’t promote those already confined to E cores to have access to P cores as well. Clair Software has added an experimental feature using setpriority() to his App Tamer utility, and confirmed this phenomenon. When that process is normally confined to running on the E cluster, that command has no effect on its core allocation or performance. Which should promote the process with PID 567 to run on both types of core. ![]() I have recently demonstrated this using the command Latest experience with using those demonstrates that, while they can be used to demote running processes to E cores, they can’t promote processes and threads which are already confined to E cores so that they can use both types. There are two methods which appear intended to change the QoS of processes: the command tool taskpolicy, and its equivalent code function setpriority(). For example, knowing that a particular backup might be large, they might elect to leave their Mac to get on with that, wanting to run it as quickly as possible. There are times when the user might wish to accelerate completion of tasks which are normally run exclusively on E cores. ![]() Apps can give the user control over the QoS of their threads, and it’s possible to run code such as command tools at a chosen QoS, but there’s no general method by which the user can control QoS, thus how fast any given process or threads will run. The lowest QoS setting of background (integer equivalent 9) confines that code to the E core cluster three higher settings allow it to be run on either E or P clusters, thus to run faster but with higher power use. Instead, core allocation is determined by setting the Quality of Service (QoS) for processes, threads and their queues. MacOS doesn’t give developers or users direct control over which type of core processes or threads are run on. User apps run their threads largely on Performance (P) cores which consume more power to complete their tasks interactively. Efficiency (E) cores are predominantly used to run services and background processes in macOS, such as making Time Machine backups and maintaining Spotlight indexes. There are two types of CPU core in Apple’s M1 chips which are used by different types of software. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |