3 ms·
The syscall in his benchmark made me laugh (https://github.com/brendangregg/Misc/blob/master/s1bench/s1bench.c#L124 https://github.com/brendangregg/Misc/blob/ma
by scott_s 9y ago
The syscall in his benchmark made me laugh (https://github.com/brendangregg/Misc/blob/master/s1bench/s1bench.c#L124 https://github.com/brendangregg/Misc/blob/master/s1bench/s1b...):
close(999); // the syscall (it errors, but so what)
- ajross 9y agoIt's surprisingly difficult to come up with a syscall that is guaranteed to enter the kernel and come back out on a fast path. Old choices for this were things like getpid() or gettimeofday() which are now handled in the VDSO. This seems fairly clever, honestly.
- pmontra 9y agoThis is a thing that generates many useless syscalls despite vDSO: https://blog.packagecloud.io/eng/2017/02/21/set-environment-variable-save-thousands-of-system-calls/ https://blog.packagecloud.io/eng/2017/02/21/set-environment-...
- Hello71 9y agogetpid is only fast on ia64 according to vdso(7).
- koverstreet 9y agomanpages can generally be assumed to be out of date
- jmgao 9y agoglibc caches getpid, so you'll only see the syscall happen after the cache gets invalidated by a call to fork, clone, etc.
- tych0 9y agoWhy not just syscall(__NR_pid)?