# Linux Kernel Module Cheat

#### 28.7.2. `getcpu` system call and the `sched_getaffinity` glibc wrapper

Examples:

- userland/linux/sched_getcpu.c

- userland/linux/getcpu.c: a wrapper close the the syscall that also returns the current NUMA node

- userland/linux/getcpu_syscall.c: the wrapper segfaults on error handling, so double checking with the real syscall: https://stackoverflow.com/questions/9260937/unix-socket-error-14-efault-bad-address/61879849#61879849

- userland/linux/sched_getcpu_barrier.c: this uses a barrier to ensure that gem5 will run each thread on one separate CPU

Returns the CPU that the process/thread is currently running on:

- https://stackoverflow.com/questions/491520/how-can-i-get-the-cpu-core-number-from-within-a-user-space-app-linux-c

- https://stackoverflow.com/questions/6026896/how-to-know-on-which-physical-processor-and-on-which-physical-core-my-code-is-ru/16574301#16574301

So when running a multicore program, we may see that each thread can be running on a different core.

The cores in which the process runs can be fixed with `sched_setaffinity` as shown at: userland/linux/sched_getaffinity.c.

So when I run it with `main` thread + 4 threads on a 4 core CPUs:

    ./userland/linux/sched_getcpu.out 4

I see random outputs like:

    7
    2
    1
    5

and:

    5
    0
    2
    1

Due to the way that gem5 syscall emulation multithreading however, the output is more deterministic in that case, see that section for further details.