getcpu(2)

✨ getcpu(2) — the manual page, but make it cute ✨

okay bestie, so this one is from the System Calls Manual (that's the 2 in getcpu(2), iykyk 🫶), and it's literally about finding out which CPU you're vibing on right now. let's go 💅

---

🌸 NAME 🌸

getcpu — figure out which CPU and which NUMA node the thread that's calling this is currently running on 🦋

---

📚 LIBRARY 📚

Standard C library (that's libc, and yeah, link it with -lc) ✨

---

🎀 SYNOPSIS 🎀

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

int getcpu(unsigned int *_Nullable cpu, unsigned int *_Nullable node);

no cap, that's the whole shape of it 💖

---

👑 DESCRIPTION 👑

so the getcpu() system call is the little system call that could: it figures out the processor and the node that the calling thread (or process) is currently running on, and writes those into the integers that cpu and node point at 🧚

• the processor is a unique small integer that identifies a CPU.
• the node is a unique small identifier that identifies a NUMA node.

and here's the cute part: if either cpu or node is NULL, then nothing gets written to that respective pointer. it just... doesn't touch it. respectful king behavior honestly 🙈

⚠️ bestie listen. the info put in cpu is guaranteed to be current only at the time of the call. unless the CPU affinity has been fixed using sched_setaffinity(2), the kernel might change the CPU at any time. (normally this doesn't happen because the scheduler tries to minimize movements between CPUs to keep caches hot, but it TOTALLY is possible.) so the caller has to allow for the possibility that whatever came back in cpu and node is already stale by the time the call returns. it's giving "screenshot at 2:47am" energy 😭

---

🔥 RETURN VALUE 🔥

• success? you get 0 back. slay. 🎉
• error? you get -1, and errno gets set to tell you what went wrong 💀

---

💀 ERRORS 💀

• EFAULT — the arguments point outside the calling process's address space. that's it, that's the only one listed. she's simple, she's iconic ✨

---

🏳️🌈 STANDARDS 🏳️🌈

Linux. that's the whole standard. just Linux 💜

---

🕰️ HISTORY 🕰️

• Linux 2.6.19 (on x86-64 and i386), glibc 2.29. vintage but make it fashion 💅

🧵 C library/kernel differences 🧵

plot twist: the kernel system call actually has a third argument:

int getcpu(unsigned int *cpu, unsigned int *node,
           struct getcpu_cache *tcache);

the tcache argument is unused since Linux 2.6.24, and (when you're invoking the system call directly) it should be specified as NULL, unless you actually need portability to Linux 2.6.23 or earlier. yes, earlier. we're going back in time for this one 🕳️🐇

and in Linux 2.6.23 and earlier? if tcache was non-NULL, then it specified a pointer to a caller-allocated buffer in thread-local storage that was used to provide a caching mechanism for getcpu(). using the cache could speed up getcpu() calls, but at the cost that there was a very small chance that the returned information would be out of date. the caching mechanism was considered to cause problems when migrating threads between CPUs, and so the argument is now ignored. rip tcache, you would've loved being useful 🪦💐

---

📝 NOTES 📝

Linux makes a best effort to make this call as fast as possible. (on some architectures, this is done via an implementation in the vdso(7). fancy 🎀)

the intention of getcpu() is to let programs make optimizations with per-CPU data, or for NUMA optimization. main character energy: it exists so your code can be fast ⚡

---

👀 SEE ALSO 👀

• mbind(2)
• sched_setaffinity(2)
• set_mempolicy(2)
• sched_getcpu(3)
• cpuset(7)
• vdso(7)

---

and that's the whole page, bestie 🫶 this was Linux man-pages 6.20, dated 2026-02-08, and the page itself is getcpu(2). go check your CPU, you're probably on a good one 🌈⭐