Understanding process priority in OS X

In this week's troubleshooting utility news and updates column we mentioned ProcessRenicer, a tool that allows users to change the scheduling priority of various processes, and discussed how this could be used to increase performance of some tasks. Some readers e-mailed in regarding this, wondering why not always change priority to make their programs run faster?

Unfortunately, changing the priority of a process does not mean you can tweak that process to make tasks magically faster on your system. Instead, it means that depending on your system's capabilities and uses, you might allow a task to respond more quickly than others on the system.

Process scheduling in OS X
In multithreaded systems such as OS X, tasks are first scheduled for processing, then dispatched to available CPUs for processing.

When tasks are scheduled for processing the system does so by balancing task complexity with various latency aspects of the task. For instance, if a task will take a lot of CPU time then it is more complex, and if the task requires interaction with a slower system component such as a hard drive then it has more latency requirements.

The preemptive scheduling in OS X checks these characteristics for running threads to see if they will hog the CPU or if they need to wait for dependencies, and then fits other tasks in so they will not be bogged down. The tasks are queued up in an "equal fairness" manner, so if two tasks are ready to be processed then the one that is queued first will be dispatched and executed first.

Using ProcessRenicer or similar programs to change this scheduling priority for a process means the scheduler will queue it up for dispatching before similar ones, provided the task's other requirements and dependencies are met.

While changing the priority of a process pushes it through the queue faster, it does not guarantee it will run before others or that it will run better; it only adjusts the special attention the thread will get from the process scheduler when the processes are queued up to be dispatched. The scheduler essentially will try to boost the process through the dispatch queue, but only if it can. There still may be requirements for various tasks that can keep the process from executing, even though it is set with a higher priority.

Ultimately, scheduling priority is a balance between how complex the current process is and how many other tasks are running and how complex they are as well. In addition, the effect of priority change is limited to the priority group (or "band") that a process is in.

Priority bands in OS X
While changing the priority of a process can make it respond faster, the scope of the change is limited to the "priority band" that the process runs in. In OS X there are several priority bands: kernel-level, and then user-level which is subsequently split into the normal, system-high, and real-time bands.

Kernel-level tasks are always given the highest priority, and user-level tasks come next. Of those, real-time threads are given the most priority because they use the system clock (predetermined numbers of CPU cycles) to time their functions, system-high processes are given the next level of priority, and then normal threads are given standard priority. Examples of these include the following:

1. Kernel-level: input management, hardware management
2. Real-time: media players, 3D games
3. System-high: higher priority tasks such as system services
4. Normal: most other user tasks

These priority bands are set in the programming for a process, and therefore are used to separate various process types. When you change the priority of a process you do so within its priority band only, so you cannot, for instance, give a user-level program more priority than a kernel-level task.

Collateral effects
Within a priority band, if you increase the priority of one process, you therefore reduce the relative priority of all other processes in that band. The increase in priority can reduce process latency, but it depends on how the system is set up. If you have a multi-CPU system with only a few processes running, then changing process priority will not have much effect, if any. However, if you have a single-CPU system that is running a number of programs, and you would like to boost the responsiveness of one of these tasks, then changing priority may help.

Are there any drawbacks?
Even though changing process priority seems like it would be a positive thing, there is a drawback, especially if a process has requirements for various shared resources it uses. If a high-priority process requires a resource but this resource is currently being used by another process that has been given artificially elevated priority, then the second process might need to wait for the first one before it can use the resource. This is called priority inversion, and can result in odd delays that can potentially lead to brief hangs and sometimes crashes, though in most cases this is only an issue if you are changing the priority of system-level processes.

Overall, while you can change the priority of a task, you may not see much difference in how it runs, and you likely will not see a notable change in its overall performance. The program might respond to user input a little better, but when running it will not use the CPU more efficiently and be faster. Therefore if you increase the priority of all the QuickTime processes, for example, they will not suddenly encode movies 20 percent faster. Also keep in mind that process priority is relative within a priority band, so if you increase the priority of all processes in the normal priority band by the same amount then you will not see any difference in behavior.

If you decide to try altering process priority, you likely will not see much difference, and you can always change the priority back or just restart the system to revert any changes to their defaults.

Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.