Linux – How to Disable One CPU

cpucpu usagelinuxnumaps

I'm trying to disable some CPUs of my server.
I've found this link: https://www.cyberciti.biz/faq/debian-rhel-centos-redhat-suse-hotplug-cpu/linux-turn-on-off-cpu-core-commands/, which offers me a method as below:

Here is what numactl --hardware gave me:
enter image description here

I want to disable all CPUs from 16 to 63, so I write a script named opCPUs.sh as below:

#!/bin/bash

for i in {16..63}; do
    if [[ "$1" == "enable" ]]; then
        echo 1 > /sys/devices/system/cpu/cpu$i/online
    elif [[ "$1" == "disable" ]]; then
        echo 0 > /sys/devices/system/cpu/cpu$i/online
    else
        echo 'illegal parameter'
    fi
done
grep "processor" /proc/cpuinfo

Then I execute it: ./opCPUs.sh disable and I can see the result of grep in the script:
enter image description here

It seems to work.

Now I think all of processes should be in CPU 0 – 15 because others have been disabled.
So I use the existing processes dbus to verify as below:
ps -Lo psr $(pgrep dbus)

I get this:
enter image description here

The psr tells me in which CPU the process is running, right? If so, I have disabled CPU 60, CPU 52 etc, why they are still here?

Best Answer

Besides @Yves answer, you actually are able to use the isolcpus kernel parameter.

To disable the 4th CPU/core (CPU 3) with Debian or Ubuntu:

In /etc/default/grub add isolcpus=3 to GRUB_CMDLINE_LINUX_DEFAULT

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash isolcpus=3"

Run 

sudo update-grub

Reboot the server.

isolcpus — Isolate CPUs from the kernel scheduler.

Synopsis isolcpus= cpu_number [, cpu_number ,...]

Description Remove the specified CPUs, as defined by the cpu_number values, from the general kernel SMP balancing and scheduler algroithms. The only way to move a process onto or off an "isolated" CPU is via the CPU affinity syscalls. cpu_number begins at 0, so the maximum value is 1 less than the number of CPUs on the system.

This option is the preferred way to isolate CPUs. The alternative, manually setting the CPU mask of all tasks in the system, can cause problems and suboptimal load balancer performance.

Interestingly enough, the usage of this kernel parameters can be setting aside a CPU for later on using CPU affinity to one process/pin a process to a CPU, and thus both making sure there are no more user processes running on that CPU.

In addition, also can make the server more stable having a guarantee a particular process with a very high load will have it´s own CPUs to play with. I have seen Meru doing that with their Linux based controllers before becoming aware of this setup.

The associated command to then assign a process to the fourth CPU (CPU 3), is:

sudo taskset -cp PID

taskset is used to set or retrieve the CPU affinity of a running process given its PID or to launch a new COMMAND with a given CPU affinity. CPU affinity is a scheduler property that "bonds" a process to a given set of CPUs on the system. The Linux scheduler will honor the given CPU affinity and the process will not run on any other CPUs. Note that the Linux scheduler also supports natural CPU affinity: the scheduler attempts to keep processes on the same CPU as long as practical for performance reasons. Therefore, forcing a specific CPU affinity is useful only in certain applications.


SUMMARY

There are several techniques applied to this question :

set isolcpus = 4 in grub and reboot can disable the 5th CPU/CPU 4 permanently for user land processes;

echo 0 > /sys/devices/system/cpu/cpu4/online disables the 5th CPU/CPU 4, that will still keep working for the processes that have already been assigned to it but no new processes will be assigned to CPU 4 anymore;

taskset -c 3 ./MyShell.sh will force MyShell.sh to be assigned to the 4th CPU/CPU 3 whereas the 4th CPU can still accept other user land processes if isolcpus is not excluding it from doing that.

PS. Anecdotally, my best example of using the isolcpus/taskset on the field, was an SSL frontend for a very busy site, that kept going unstable every couple of weeks, where Ansible/ssh would not let me in remotely anymore.

I applied the techniques discussed above, and it kept working in a very stable fashion ever since.

Related Question