I need to run performance tests for my concurrent program and my requirement is that it should be run on only one CPU core. (I don't want to cooperative threads - I want always have a context switching).

So I have two questions:

  1. The best solution - How to sign and reserve only one CPU core only for my program (to force OS to not use this CPU core). I guess it is not possible but maybe I'm wrong...

  2. How to set linux (Fedora 24) to use only one CPU core?

  • See this. Commented Oct 21, 2016 at 22:41
  • 1
    Note that modern CPUs can change their speed depending on how many cores are in use in total. Even if you make sure that your process is only using a single core and no other process is using it, the speed of that core will differ depending on how the operating system will use the other cores. Take this into account when running your tests.
    – liori
    Commented Oct 22, 2016 at 0:44
  • You should be able to deactivate CPU cores from the BIOS, maybe is more reliable for your tests as @liori stated above that the OS could be altering core speed.
    – Marcs
    Commented Oct 23, 2016 at 12:00
  • What about creating a VM and assigning only one core to it? Oh, I just read the "to not use this CPU core" so never mind...
    – sakisk
    Commented Oct 27, 2016 at 20:09
  • Related: Telling Linux kernel not to use certain CPUs
    – ilkkachu
    Commented Oct 2, 2018 at 16:21

1 Answer 1


On linux, the system call to set the CPU affinity for a process is sched_setaffinity. Then there's the taskset tool to do it on the command line.

To have that single program run on only one CPU, I think you'd want something like

taskset -c 1 ./myprogram

(set any CPU number as an argument to the -c switch.)

That should be close enough to a single-processor system, as long as your other processes don't run too much compared to the one you want to measure, or they get scheduled to other CPU's. If you want to dedicate one CPU to that single process only, and prevent other processes from running on that CPU, you'd need to set their affinity too.

That, I don't know how to do properly. You'd need to set the processor affinity of init very early in the boot process to make sure it gets inherited to all processes on the system. As a workaround, you could use taskset -c -p 0 $PID for all other processes to force them to run on CPU #0 only.

systemd also has CPUAffinity= to control the affinity in unit files and there are a couple of questions on setting the default affinity here on unix.SE, but I didn't find any with a good solution.

Though as @Kamil Maciorowski commented and answered to another question on superuser.com, setting isolcpus=1 on the kernel command line should "isolate that CPU from the general scheduling algorithms", which is something you may want.

  • This doesn't quite answer the question. While taskset (or other methods of setting task affinity) will ensure that a process runs only on the specified set of cores, it won't guarantee that only that process will run on those cores. That is to say, the operating system could schedule other processes on to the core you have set your process affinity to. In practice, this is the most useful answer, but be aware of the limitations, and in particular be aware that it doesn't give what you ask for in 1) "reserve only one cpu core only for my program (to force OS to not use this cpu core)" Commented Oct 21, 2016 at 20:47
  • @JamesGreenhalgh, but, finding a way to set the CPU affinity for every process would answer the question. Is it possible to set a default cpu affinity for new processes, as a kernel (cmd line) option? That would take effect early in the boot process, and affect all processes.
    – jpaugh
    Commented Oct 21, 2016 at 21:50
  • I actually missed the clause in parenthesis about preventing other processes from running on that CPU. Or perhaps I thought the biggest problem would be to make sure that the program under question would run on only one core, instead of say, four, and that the other processes could be considered a kind of a nuisance, which wouldn't matter much compared to that. But I'll admit, I didn't have a proper answer to that part of the question, apart from what Kamil commented now.
    – ilkkachu
    Commented Oct 21, 2016 at 22:54
  • @jpaugh, I think even then you would be unable to completely isolate yourself from the possibility of another process executing on "your" core. For example, one which reset its own affinity, or even kernel code itself consuming time unrelated to management of your process. Again, I fully agree that in practice, this answer is what most would do to solve the bulk of the problem, but I would be really interested in reading an answer to that final part in parenthesis! Commented Oct 22, 2016 at 7:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .