What is Windows Priority and Affinity and what advatanges does it provide?

What exactly is Priority and Affinity (found within Task Manager) and what are they used for:

In what situations should/could they be used and what advantages are found while customizing these setting.

Solution 1:

Setting affinity does do something, but you'll never want to use it.

Setting the CPU affinity forces Windows to only use the CPU (or cores) selected. If you set the affinity to a single CPU, Windows will only run that application on that CPU, never on any others.

Windows automatically puts run applications on the least-busy processor, so limiting it to a single CPU doesn't let Windows do its job. Even if CPU/core 1 is busy running other applications, Windows won't be able to run an application with affinity set on CPU/Core 2.

Really the only reason you would want to do that is to run an old application that doesn't work correctly when running on a multi-CPU/Core system.

Solution 2:

This is a very useful feature in certain scenarios. Let's say you have a multi-threaded application that tends to either be idle or aggressively grabbing 100% of every CPU for several minutes, doing searches, builds, etc. Let's call this application "eclipse."

Let's also say that while you're working on this application, you have a bunch of other applications that have modest cpu requirements, but are essentially real-time applications. For example, while you're using Eclipse and it is randomly kicking off builds or doing gwt compiles, you're also using your computer to stream music or perform research in a browser window (for example, researching the cause of a build problem). Sure, you will not die if your music skips or your browser stops responding, but it's annoying.

What affinity lets you do is confine your cpu eating app to 7/8 cores so that everyone else is guaranteed access to a relatively unused cpu and you don't constantly have to deal with stuttering and interruptions to the usability of everything else on your computer while eclipse is grinding away.

Solution 3:

Setting affinity tells that process what processors it's allowed to run on.

While very useful for some niche cases, the average user probably shouldn't mess with it.

For instance if a process were allowed its own core to run it could run in (near) real-time without those 70 windows utilities constantly interrupting and stack-swapping on the processor for their own time slice. Real-time applications were something that windows could never do before multi-processor/multi-core systems hit the scene because the OS would constantly be interrupting/task-switching the application for its own purposes. That can now mostly be overcome by isolating the real-time application one processor while preventing all the other applications in the system from using that processor. This is a very niche subject but systems like (real) flight simulators, factory automation, and control feedback systems depend on real-time architecture to work.

Processor intensive applications (like VMs) can be isolated to their own core so you can use them without bringing the rest of your system to a crawl. In theory, a hypervisor running on a processor that supports bare-metal hypervisor interaction can reach processor performance equal to independent OS running on its own (minus the processor needed to run the host OS). Of course, in practice even a VM running on its own isolated core/processor will still need to accept small amount of overhead from the host the host OS.

For applications that handle a large amount of data in flux, isolating the application to its own processor (and potentially still utilizing multiple cores) will cut down on cache swapping.

Older applications that break when they're spread across multiple processors can effectively be limited to one core/processor to fix the issue.

If you were doing performance measurements on a specific application, it's near impossible to get consistent results across different systems unless you can isolate the process because, otherwise, you have no control over how much time the OS gives your application. Most people agree that measuring runtime performance doesn't give good results but those people have never considered that the OS intervention (that makes results so inconsistent) can be limited by using affinity.

There are plenty of cases where affinity is vital but, if you don't know what they are, you probably won't need it.