sched_setaffinity(2)

💅 sched_setaffinity(2) — System Calls Manual 💅

okay bestie, gather round, because today we're talking about the ✨ sched_setaffinity ✨ and ✨ sched_getaffinity ✨ system calls — that's the <pink>System Calls Manual</pink>, section 2, if you're keeping track. This is the whole "which CPUs is my thread even allowed to run on" situation, and ngl it's lowkey iconic.

🌸 NAME 🌸

sched_setaffinity, sched_getaffinity — set and get a thread's CPU affinity mask 💖

📚 LIBRARY 📚

Standard C library (libc, -lc) 🫶

✨ SYNOPSIS ✨

okay so first things first, you gotta have _GNU_SOURCE defined or none of this is happening, fr fr:

#define _GNU_SOURCE             /* See feature_test_macros(7) */
#include <sched.h>

int sched_setaffinity(pid_t pid, size_t cpusetsize,
                      const cpu_set_t *mask);
int sched_getaffinity(pid_t pid, size_t cpusetsize,
                      cpu_set_t *mask);

👑 DESCRIPTION 👑

So. A thread's CPU affinity mask is literally just the set of CPUs it's eligible to run on. That's it, that's the whole vibe. And on a multiprocessor system, setting that mask can actually get you some real performance benefits. Like, for example: dedicate one single CPU to a particular thread — meaning you set that thread's affinity mask to exactly one CPU, and then set the affinity mask of every other thread to exclude that CPU — and boom, you've basically guaranteed maximum execution speed for that special thread. Main character energy, honestly. 💅

Also? Restricting a thread to run on a single CPU means you avoid the performance cost that comes from cache invalidation — the sad little thing that happens when a thread stops running on one CPU and then starts up again on a different CPU. So rude of the scheduler to do that to it.

A CPU affinity mask is represented by the cpu_set_t structure — a "CPU set" — which is the thing mask points to. There's a whole family of macros for poking at CPU sets, and those are described over in CPU_SET(3). Go look, it's a good time.

<sched_setaffinity>sched_setaffinity()</sched_setaffinity> sets the CPU affinity mask of the thread whose ID is pid to whatever value you put in mask. And if pid is zero, then it's the calling thread we're talking about. The cpusetsize argument is the length (in bytes) of the data that mask points to. Normally you'd just pass sizeof(cpu_set_t) there, easy peasy.

And here's a cute detail: if the thread specified by pid isn't currently running on one of the CPUs listed in mask, then that thread gets migrated to one of the CPUs specified in mask. Like, pack your bags bestie, we're moving. 🦋

<sched_getaffinity>sched_getaffinity()</sched_getaffinity> does the opposite — it writes the affinity mask of the thread whose ID is pid into the cpu_set_t structure pointed to by mask. The cpusetsize argument here specifies the size (in bytes) of mask. And again, if pid is zero, you get back the mask of the calling thread.

---

🎀 RETURN VALUE 🎀

On success, sched_setaffinity() and sched_getaffinity() return 0. But wait — there's a lil plot twist, so peep the "C library/kernel differences" section down below, because the underlying sched_getaffinity() is not the same girl when it comes to return value. 🙈

On failure, -1 is returned, and errno gets set to tell you what went wrong.

💀 ERRORS 💀

• EFAULT — A supplied memory address was invalid. Like girl, that pointer is not pointing anywhere valid. 😭
• EINVAL — 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).
• EINVAL — (sched_getaffinity() and, before Linux 2.6.9, sched_setaffinity()) cpusetsize is smaller than the size of the affinity mask used by the kernel. Your buffer is too smol, bestie. 🍓
• EPERM — (sched_setaffinity()) The calling thread does not have appropriate privileges. The caller needs an effective user ID equal to the real user ID or effective user ID of the thread identified by pid, or it must possess the CAP_SYS_NICE capability in the user namespace of the thread pid. iykyk — no perms, no party. 👑
• ESRCH — The thread whose ID is pid could not be found. She's not here, she's gone, 💀.

🌈 STANDARDS 🌈

Linux. That's it. That's the standard. ✨

📜 HISTORY 📜

• Linux 2.5.8, glibc 2.3.
• So initially, the glibc interfaces included a cpusetsize argument, and it was typed as unsigned int. Then in glibc 2.3.3, the cpusetsize argument got removed — but then it was restored in glibc 2.3.4, this time with type size_t. Not the glow-up arc nobody expected. 💖

📝 NOTES 📝

So after you call sched_setaffinity(), the set of CPUs your thread will actually run on is the intersection of the set you specified in the mask argument and the set of CPUs that are actually present on the system. And the system can restrict it even more if the "cpuset" mechanism from cpuset(7) is in play. All these restrictions on the actual set of CPUs your thread runs on? Silently imposed by the kernel. No warning, no note, it just does it. 🙈

There's a bunch of ways to figure out how many CPUs are available on your system, including:

• inspecting the contents of /proc/cpuinfo;
• using sysconf(3) to obtain the values of the _SC_NPROCESSORS_CONF and _SC_NPROCESSORS_ONLN parameters;
• and inspecting the list of CPU directories under /sys/devices/system/cpu/.

sched(7) has a description of the Linux scheduling scheme, if you wanna go deeper.

Also important: the affinity mask is a per-thread attribute, meaning it can be adjusted independently for each of the threads in a thread group. The value returned from a call to gettid(2) can be passed in the argument pid. Specifying pid as 0 will set the attribute for the calling thread, and passing the value returned from a call to getpid(2) will set the attribute for the main thread of the thread group. And pssst — if you're using the POSIX threads API, then use pthread_setaffinity_np(3) instead of sched_setaffinity(). Just do it, trust. 🫶

The isolcpus boot option can be used to isolate one or more CPUs at boot time, so that no processes are scheduled onto those CPUs. After you use this boot option, the only way to schedule processes onto the isolated CPUs is via sched_setaffinity() or the cpuset(7) mechanism. For more info, see the kernel source file Documentation/admin-guide/kernel-parameters.txt. And as noted in that file, isolcpus is the preferred mechanism of isolating CPUs — versus the alternative of manually setting the CPU affinity of every single process on the system. Yeah. Nobody has time for that. 😭

A child created via fork(2) inherits its parent's CPU affinity mask. And the affinity mask is preserved across an execve(2). Slay, continuity. ✨

🧚 C library/kernel differences 🧚

This manual page describes the glibc interface for the CPU affinity calls. The actual system call interface is slightly different — the mask is typed as unsigned long *, which reflects the fact that the underlying implementation of CPU sets is a simple bit mask. Same energy, different outfit. 💅

On success, the raw sched_getaffinity() system call returns the number of bytes placed copied into the mask buffer; this will be the minimum of cpusetsize and the size (in bytes) of the cpumask_t data type that is used internally by the kernel to represent the CPU set bit mask. (Yes, that sentence says "placed copied". We keep it verbatim, bestie, we don't rewrite lore. 🫶)

🍓 Handling systems with large CPU affinity masks 🍓

Okay here's where it gets hairy. The underlying system calls — which represent CPU masks as bit masks of type unsigned long * — impose no restriction on the size of the CPU mask. However! The cpu_set_t data type used by glibc has a fixed size of 128 bytes, meaning the maximum CPU number that can be represented is 1023.

So if the kernel CPU affinity mask is larger than 1024, then calls of the form:

sched_getaffinity(pid, sizeof(cpu_set_t), &mask);

fail with the error EINVAL — which is the error produced by the underlying system call for the case where the mask size specified in cpusetsize is smaller than the size of the affinity mask used by the kernel. And depending on the system CPU topology, the kernel affinity mask can be substantially larger than the number of active CPUs in the system. So like, way bigger. 😳

When you're working on systems with large kernel CPU affinity masks, you must dynamically allocate the mask argument — see CPU_ALLOC(3). And currently, the only way to do this is by probing for the size of the required mask using sched_getaffinity() calls with increasing mask sizes, until the call does not fail with the error EINVAL. It's giving trial and error, but make it system calls.

⚠️ Be aware that CPU_ALLOC(3) may allocate a slightly larger CPU set than requested — because CPU sets are implemented as bit masks allocated in units of sizeof(long). Consequently, sched_getaffinity() can set bits beyond the requested allocation size, because the kernel sees a few additional bits. So the caller should iterate over the bits in the returned set, counting those which are set, and stop upon reaching the value returned by CPU_COUNT(3) — rather than iterating over the number of bits requested to be allocated. Do not skip this, bestie, it will bite you. 🙈

---

🔥 EXAMPLES 🔥

The program below creates a child process. The parent and child then each assign themselves to a specified CPU and execute identical loops that consume some CPU time. Before terminating, the parent waits for the child to complete. The program takes three command-line arguments: the CPU number for the parent, the CPU number for the child, and the number of loop iterations that both processes should perform.

As the sample runs below demonstrate, the amount of real and CPU time consumed when running the program will depend on intra-core caching effects and whether the processes are using the same CPU. 👀

We first employ lscpu(1) to determine that this (x86) system has two cores, each with two CPUs:

$ lscpu | egrep -i 'core.*:|socket';
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1

We then time the operation of the example program for three cases: both processes running on the same CPU; both processes running on different CPUs on the same core; and both processes running on different CPUs on different cores.

$ time -p ./a.out 0 0 100000000;
real 14.75
user 3.02
sys 11.73
$ time -p ./a.out 0 1 100000000;
real 11.52
user 3.98
sys 19.06
$ time -p ./a.out 0 3 100000000;
real 7.89
user 3.29
sys 12.07

🌸 Program source 🌸

okay here's the full source, character-for-character, don't @ me:

#define _GNU_SOURCE
#include <err.h>
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
    int           parentCPU, childCPU;
    cpu_set_t     set;
    unsigned int  nloops;

    if (argc != 4) {
        fprintf(stderr, "Usage: %s parent-cpu child-cpu num-loops\n",
                argv[0]);
        exit(EXIT_FAILURE);
    }

    parentCPU = atoi(argv[1]);
    childCPU = atoi(argv[2]);
    nloops = atoi(argv[3]);

    CPU_ZERO(&set);

    switch (fork()) {
    case -1:            /* Error */
        err(EXIT_FAILURE, "fork");

    case 0:             /* Child */
        CPU_SET(childCPU, &set);

        if (sched_setaffinity(0, sizeof(set), &set) == -1)
            err(EXIT_FAILURE, "sched_setaffinity");

        for (unsigned int j = 0; j < nloops; j++)
            getppid();

        exit(EXIT_SUCCESS);

    default:            /* Parent */
        CPU_SET(parentCPU, &set);

        if (sched_setaffinity(0, sizeof(set), &set) == -1)
            err(EXIT_FAILURE, "sched_setaffinity");

        for (unsigned int j = 0; j < nloops; j++)
            getppid();

        wait(NULL);     /* Wait for child to terminate */
        exit(EXIT_SUCCESS);
    }
}

---

💖 part 2 incoming, bestie — do NOT close the tab, there's more tea to spill 💖

🔭 SEE ALSO — aka ur reading list bestie ✨

okay so you survived the whole page 💖 which, slay, honestly. But no page is an island and this one is literally holding hands with a whole friend group of other man pages. Go say hi. They're all one man away, no cap:

the section 1 girlies (user commands, ur fave little CLI besties)

• lscpu(1)
• nproc(1)
• taskset(1)

the section 2 girlies (syscall central, main character energy fr)

• clone(2)
• getcpu(2)
• getpriority(2)
• gettid(2)
• nice(2)
• sched_get_priority_max(2)
• sched_get_priority_min(2)
• sched_getscheduler(2)
• sched_setscheduler(2)
• setpriority(2)

the section 3 girlies (library calls, the ones u actually #include)

• CPU_SET(3)
• get_nprocs(3)
• pthread_setaffinity_np(3)
• sched_getcpu(3)

the section 7 girlies (big-picture overviews, the lore 💅)

• capabilities(7)
• cpuset(7)
• sched(7)

the section 8 girly (sysadmin territory, respect)

• numactl(8)

---

ngl bestie, if u only click ONE thing from this list, make it sched(7) — it's the whole scheduling saga in one sitting and u will ✨understand things✨. And if ur vibe check says "wait, what CPUs do I even have", that's lscpu(1) and nproc(1) knocking on ur door 🫶

---

k that's literally the whole page, we made it to the end together 😭💖 this little beauty comes from Linux man-pages 6.20, dated 2026-02-08, and it lives under the name sched_setaffinity(2) — say it with me one time for the girlies 👑 periodt, go bind urself to a CPU and thrive 🦋✨