Use much faster getcpu() via vDSO

[jserv]

vDSO (virtual dynamic shared object) is exported by Linux kernel into every userspace program, designed to speed up this process for certain system calls. For Linux/x86_64, getcpu() can be called via vDSO, which
makes getcpu() much faster. The faster getcpu() invocation is beneficial when retrieving NUMA node information.

Benchmarking on AMD Ryzen Threadripper 2990WX 32-Core Processor:

  getcpu: syscall: 103 nsec/call
  getcpu:    vdso: 18 nsec/call

[LifeIsStrange]

@jserv noob question: why doesn't the default GLIBC getcpu() doesn't leverage vdso?

[jserv]

@jserv noob question: why doesn't the default GLIBC getcpu() doesn't leverage vdso?

In glibc development, getcpu was absent until the commit on Dec 7, 2018. That is the reason why mimalloc uses syscall to invoke getcpu. Then, glibc version 2.29 included getcpu system call wrapper. vDSO path can be enabled since glibc-2.29, but not every major Linux distribution ships with glibc-2.29+. For example, Red Hat Enterprise Linux 8 uses glibc-2.28.

[LifeIsStrange]

Thanks for your technical excellence :)

[scottlamb]

In glibc development, getcpu was absent until the commit on Dec 7, 2018. That is the reason why mimalloc uses syscall to invoke getcpu. Then, glibc version 2.29 included getcpu system call wrapper. vDSO path can be enabled since glibc-2.29, but not every major Linux distribution ships with glibc-2.29+. For example, Red Hat Enterprise Linux 8 uses glibc-2.28.

Did you consider the alternative of using the libc wrapper when available at compile time (as detected via say __GLIBC__ and __GLIBC_MINOR__ defines / like musl macros, or configure-time probe) and the syscall path otherwise?

Pros:

• simplicity.
• faster on recent glibc + aarch64

Cons:

• doesn't give the speedup on x86-64 systems when running kernel new enough to support the vDSO but compiled with a glibc/musl too old to support it. But how common is this really?