28.7.2. getcpu system call and the sched_getaffinity glibc wrapper
Examples:
-
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:
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.