Sometimes, it denies some threads to execute on some CPU cores. It chooses the best CPU core to be used to execute a particular thread. Threads get to run on any of the core whichever available at that time. So it will be helpful as it doesn’t wait for a particular core of CPU to be available. If you don’t set affinity, a thread can be run on any core of CPU. It helps to reserve particular core of CPU for a particular thread to be executed on. The CPU affinity is a setting provided by the operating system. There is one more term very important to know about the execution of the program- CPU affinity. If you are reading this article, you might be already aware of the process and threads in the operating system. These process and threads get executed on CPU cores.

And one process may contain multiple threads. If someone could edit in a link to documentation that explains this, that would be helpful.Whenever you run any application on your computer, it creates an instance of that application, called a process.

burn_cycles.py &Īpparently threads spawned before the parent process' affinity is changed don't inherit the affinity of their parent. This replicates the 'taskset does nothing' results I described above. That result contrasts with this method, which is exactly the same but allows the Python threads to spawn before setting the affinity of the Python process. burn_cycles.py & taskset -pc 0 `pgrep python` So, the Python process was started, then it was set to run on CPU 0, then it spawned its threads, which inherited the proper affinity. Note from the output that the Linux scheduler finished executing the Bash commands before spawning the Python threads. Interestingly, launching the Python script and then immediately using taskset to set the just-started process' affinity caps the process at 100%. Watching top shows the Python process pegged at 100% usage. Launching my Python script with taskset works as expected. Just running the Python script eats up about 150% CPU usage. Thread = threading.Thread(target=cycle_burner) The idea is to test taskset against it, as it's quite simple. I wrote a Python script that simply spins up some threads and burns CPU cycles. Update: Newer versions of taskset have a -a/ -all-tasks option that 'operates on all the tasks (threads) for a given pid' and should solve the behavior I show below.

Process affinity not being set