Close this search box.

How To Persist CPU and IO Priority For A Process

Recently I have looked at the system startup time of my PC which does have a quite high boot time. Luckily WPR from the Windows Performance Toolkit does allow you to capture boot traces without much effort. You only need to select Boot as Performance scenario and the number of boots you want to perform to capture data. The default is three which I normally reduce to one because I have no regression test going on.

Then you can easily check if a script of your administrators did take too long. Or if the virus scanner is getting out of hand by causing too much disc IO. One thing I did notice on my machine was that a system service was stopped, deleted and created again. While deleting a service the sc delete call did hang for 70s because Windows did think that the service was still starting up and did give up only after quite a long time. After that was fixed a netsh call did hang also for 70s which did try to disable IPv6 but only after the IPv6 subsystem was started. Besides these two hangs my boot was practically disc bound. So I did look which processes do hit the disc hard but delay other more important tasks. One obvious thing was some monitoring software which does read quite a lot of data during boot. Since Windows does support IO priorities and you can change them with tools like Process Hacker (it is better than Process Explorer from SysInternals for many tasks). I thought it would help a bit to lower the CPU and IO priority of some unimportant processes during the boot phase to get faster to my desktop. There are many tools out there to change the priorities of running processes but there are very few tools out there to persist it automatically once a process is started. Process Hacker for example can remember for a specific process the settings and reapply it when it is running. But during the boot no tool like process hacker is running. There are other commercial tools out there which seem to do the same thing but since I am a programmer I can write my own tool.

My own tool? No. I was just kidding. Who needs a tool? This functionality is already baked into Windows since Windows Vista! I have found surprisingly little information about this feature on the net. But here it is. The Registry Key is Image File Execution Options where you can set the CPU and IO priority for an executable manually. You only need to create a registry key like

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\cmd.exe\PerfOptions

In the example above I want to set for cmd.exe the CPU and IO priority. For this I do need to set two DWORD values named CpuPriorityClass and IoPriority below the PerfOptions key. With a little bit experimentation I have found the values which do something:

CpuPriorityClass ValuePriority
5Below Normal
6Above Normal
IoPriority ValuePriority
0Very Low

All other values set the priority back to normal. This should help to get a few more seconds out during the boot phase. I can only speculate why MS did not document these settings. As usual it is dangerous to tinker with priorities because the OS Scheduler might never schedule any IO or CPU time slice for a process when other processes with higher priorities are constantly running. Besides that if too many processes use this feature it becomes quickly useless which might be the main reason not to document it. Too many people will misuse such features to shoot themselves in the foot and later complain that there was not safety warning message box telling them to not shoot themselves in the foot. If you know that you are doing unimportant stuff you should use the Windows APIs to set your process into background processing mode which will lower the CPU and IO priority for for the whole process. Additionally there exists  SetThreadPriority which does the same for only one thread inside your process. But you should be aware of the fact that your stuff might never run if there is constant load on the machine with more important tasks.

posted on Wednesday, August 14, 2013 11:10 AM

This article is part of the GWB Archives. Original Author: Alois Kraus

Related Posts