Multi-core processing can have benefits and drawbacks, and sometimes you need to manually assign CPU cores to programs (aka “CPU affinity”) in order to gain the best performance. Under Linux, the primary tool is taskset. That sounds potentially scary, but we’ll break it down into easy steps to simplify the process.
Using taskset can be broken down into two parts: CPU affinity with programs to be launched and with programs already running. Launching programs is the easier of the two, so we’ll start there. A launch command looks like this:
Before you enter the number of the CPU core you want to assign, don’t forget that a Unix numbering scheme typically starts at 0, so your first core will be 0, your second core 1, and so on. Thus, a dual-core machine will have cores 0 and 1, and a quad-core machine will have cores 0, 1, 2, and 3.
Let’s say you want to run Audacity on a dual-core system, and you want it running on your second core. That command would be:
Using Multiple Cores
On one of our machines, Chrome would sometimes drop frames when streaming video but would behave itself when assigned to two cores. If you want to try the same thing on a quad-core system and wish to assign Chrome to cores three and four, the command would be:
You don’t have to assign CPU affinity to sequential cores – you can pick any core(s) at random. Let’s say you have a six-core machine and want to use Chrome on cores two and six. You would enter the command:
You can also use a dash to spread an application over several cores. For instance, many older programs or system functions will default on your first core. What if you wanted to leave the first core as free as possible while spreading a large application across all your other cores?
Let’s say you have an eight-core system and want to run Steam from the second core through to the eighth. That command would be:
Changing Affinity for a Program that’s Already Launched
Taskset isn’t limited simply to launching applications. You can also change the CPU affinity for a program that’s already running. However, before you can change an application’s affinity, you first need to know its Process ID (or PID for short).
To find out your application’s PID, you could try using your desktop’s system monitor, but the quickest way is just to use
top. Unsurprisingly, it uses the command:
The names of all running commands are on the right side of the screen. The corresponding Process IDs are on the left.
Write down your PID as you’ll use it in a moment. For this example, we’ll use VLC, which is in the middle of playing a high-definition Matroska video on an older PC with six cores. We’re experimenting with different CPU affinities in order to squeeze the best performance from VLC.
To change the affinity of an existing process, the syntax looks like this:
If you can see our screenshot above, VLC’s Process ID is 20485. We’re going to try running VLC on the fourth, fifth, and sixth cores, which in Unix numbering will be 3-5. So after all that, the command will be:
But what if you want to check out the existing affinity before changing it? For that, don’t enter any core numbers, and taskset will tell you how the affinity is assigned. So if we change the last command to:
it shows us that VLC is spread across all of the cores.
Let’s try that again with a different program. Let’s say we run a big Matroska with SMPlayer instead, and SMPlayer has already been launched. Top says the PID is 16058.
But first we want to know its existing affinity. Using the command with the
-cp switch but no core numbers, we can see the affinity is currently spread across all cores.
Now we can try spreading SMPlayer across the same three cores as the VLC experiment with the command:
That is easy, isn’t it? If you are looking to benchmark your PC, do check out our guide on 8 useful tools to stress-test your CPU.