First, let me give a background of what I am trying to achieve. I know how to isolate a particular CPU using boot param (isolcpu and nohz_full; the housekeeping subsystem setup).

But as per my requirement, I need to isolate the CPU after the system has booted up. So, as per many articles, I tried to isolate a particular CPU using cpuset subsystem as follows:

I am using a hardware having 16 cpus. (0-15). So, I decided to isolate CPU 0.

$ cd /cpusets
$ mkdir housekeeping
$ mkdir isolate
$ echo 1-15 > housekeeping/cpus
$ echo 0 > mems
$ echo 0 > isolated/cpus
$ echo 0 > isolated/mens
$ echo 0 > cpuset.sched_load_balance
$ echo 0 > isolated/sched_load_balance
$ while read P ; do echo $P > housekeeping/tasks ; done < tasks

This isolates the processor 0 from all the other processors. But when I tried to assign a process to processor 0 using taskset as follows:

int main(){
    int i;
    return 0;
$ gcc -o loop.c loop
$ taskset -c 0 ./loop
taskset: failed to set pid 2755250's affinity: Invalid argument 

Apart from echoing pid 2755250 to isolated/tasks, is it possible to set the affinity of a new process to the isolated CPU 0?

Where am I making a mistake?

  • 1
    off-topic, but if you want to write an infinite loop in C, while(true){} for for(;;){} are much more idiomatic. Your code uses i uninitialized, and has undefined behaviour on signed-integer overflow. If you wanted to slow the loop down by introducing a data dependency through memory in a debug build, use for (unsigned i=0; ; i++) so wrap-around is well-defined. It doesn't actually matter in a debug build with a normal compiler for a normal ISA, though; the compiler will still make the same asm (except for actually initializing if you don't omit it), but it seems like a better habit. Jan 22 at 20:31

1 Answer 1


taskset will call sched_setaffinity which will fail if

The affinity bit mask mask contains no processors that are currently physically on the system and permitted to the thread according to any restrictions that may be imposed by cpuset cgroups or the "cpuset" mechanism described in cpuset(7).

As for why is the behaviour different when resorting to the isolcpus= boot parameter, please note in your kernel documentation (Documentation/admin-guide/kernel-parameters.txt) that this can be overidden at runtime by the CPU affinity syscalls

You can move a process onto or off an "isolated" CPU via the CPU affinity syscalls or cpuset.

Contrarily, man cpuset will tell that cpuset placement is enforced in case of conflicting setting from sched_setaffinity.

Cpusets are integrated with the sched_setaffinity(2) scheduling affinity mechanism and the mbind(2) and set_mempolicy(2) memory-placement mechanisms in the kernel. Neither of these mechanisms let a process make use of a CPU or memory node that is not allowed by that process's cpuset. If changes to a process's cpuset placement conflict with these other mechanisms, then cpuset placement is enforced even if it means overriding these other mechanisms. The kernel accomplishes this overriding by silently restricting the CPUs and memory nodes requested by these other mechanisms to those allowed by the invoking process's cpuset. This can result in these other calls returning an error, if for example, such a call ends up requesting an empty set of CPUs or memory nodes, after that request is restricted to the invoking process's cpuset.

BTW : Please also note (in the kernel documentation) that the isolcpus= boot parameter is deprecated.

  • Please could you help me understand, what changes are made by cpuset (which were not made by the isolcpu bootparam) which in turn is causing this side effect? Would like to dig more into it... in the line of a possible kernel patch for my requirement, if necessary... Jan 22 at 12:16
  • 1
    @AbhishekGhosh : I reedited my answer for what concerns on difference between the isolcpus boot parameter and the cpuset ways. (This incidentally making me think (since it is a feature) that a kernel patch working this around has got poor chances to make its way)).
    – MC68020
    Jan 22 at 13:59
  • thanks for the pointers... Jan 22 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.