The Need for CPU Pinning
In a standard Linux environment, the kernel’s completely fair scheduler (CFS) is responsible for distributing the workload. If you launch a multi-threaded database application on a 16-core server, the kernel will constantly migrate those threads across all 16 CPUs to balance the thermal load and maximize overall efficiency.
However, for extreme high-performance computing—such as High-Frequency Trading (HFT) algorithms, real-time video encoding, or massive Redis in-memory databases—this constant CPU migration introduces unacceptable latency. Every time a thread moves from CPU Core 1 to CPU Core 4, it loses the L1 and L2 hardware cache built up on Core 1, forcing a slow fetch from main RAM.
To achieve maximum bare-metal performance, system administrators use CPU Affinity to “pin” a specific process to a specific CPU core. You can achieve this using the taskset command.
Understanding CPU Masks
The taskset command uses a hexadecimal mask to represent the available CPU cores. For example, if you have a 4-core machine (Cores 0, 1, 2, 3), the binary representation of “Core 0” is 0001 (Hex 1). “Core 3” is 1000 (Hex 8).
Fortunately, you do not have to calculate hex codes. You can use the -c (cpu-list) flag to specify human-readable core numbers.
Checking Current Affinity
First, identify the Process ID (PID) of the application you want to optimize (e.g., PID 4567). Let’s see its current CPU affinity.
taskset -c -p 4567The output will likely say pid 4567's current affinity list: 0-15. This indicates that the Linux kernel is actively migrating the process across all 16 available cores on the server.
Pinning a Running Process
Let’s assume you want to dedicate Cores 14 and 15 exclusively to this database process to ensure its L2 cache remains perfectly hot.
Execute the following command as root:
sudo taskset -c -p 14,15 4567The terminal will confirm the change: pid 4567's new affinity list: 14,15. The kernel immediately restricts that specific process (and all its child threads) to only execute on physical cores 14 and 15. It will never migrate to core 0.
Launching a New Process with Affinity
Instead of pinning a process after it has already launched, you can wrap the execution command with taskset so that the application is birthed onto a specific core.
If you have a custom financial script (algo.sh) that must run entirely on Core 0, run:
taskset -c 0 ./algo.shThe Risk of CPU Starvation
While pinning a critical database to Cores 14 and 15 is excellent for the database, the Linux kernel might still decide to schedule an OS background task (like a systemd journal flush) onto Core 14, interrupting your database.
To achieve true real-time isolation, you must isolate the CPU at the bootloader (GRUB) level using the isolcpus kernel parameter. If you add isolcpus=14,15 to your GRUB config, the Linux kernel will mathematically ignore those two cores for general scheduling. They will sit completely idle at 0% usage. The only way any code will ever execute on those isolated cores is if you explicitly force it there using the taskset command, providing absolute, uninterrupted bare-metal performance for your critical application.