5 ms·
That’s ignoring the other costs of syscalls like evicting your stuff from the CPU caches. But I agree with the conclusion, system calls are still pretty fast c
by slashdev 5mo ago
That’s ignoring the other costs of syscalls like evicting your stuff from the CPU caches.
But I agree with the conclusion, system calls are still pretty fast compared to a lot of other things.
- vlovich123 5mo agoSmall correction on ambiguous wording - syscalls do not evict all your stuff from CPU caches. It just has to page in whatever is needed for kernel code/data accessed by the call, but that’s no different from if it was done in process as a normal function call.
- Polizeiposaune 5mo agoDepending on implementation details of your CPU and OS, the syscall path may need to flush various auxillary caches (like one or more TLBs) to prevent speculation attacks, which may put additional "drag" on your program after syscall return.
- vlovich123 5mo agoCorrect but you’d also still have that drag just from the kernel dirtying those caches in the first place. But I was clarifying because the wording could be taken as data/instruction cache and there generally isn’t a full flush of that just to enter/leave kernel.
- slashdev 5mo agoYes, that’s right. It seems to make up the bulk of the cost of a system call though, depending what it does, like read or write syscalls.