4 ms·
> The advantage is that you can context switch between threads without having to syscall, which speeds up things substantially. There's still a syscall, but it
by wahern 6y ago
> The advantage is that you can context switch between threads without having to syscall, which speeds up things substantially.
There's still a syscall, but it doesn't enter the kernel scheduler or other machinery, which is where most of the time is spent.
Linux syscall overhead (switching into ring 0) was and remains (apparently[1]) miniscule, which is why Linux ended up with 1:1 thread scheduling. But everything else--what those syscalls do--has grown in complexity. The original calculus for rejecting userspace scheduler activations and M:N threading for 1:1 threading no longer holds. What's old is new again.
[1] Would be interesting to know if Google's kernels employ all the new Spectre mitigations.
- anitil 6y agoI'm only part way through the proposal, but perhaps this would be a candidate for being placed in the vDSO so there's no context switch at all.
- wahern 6y agoA vDSO can't transfer execution to another thread. Theoretically a vDSO could manipulate a thread's scheduling context to move it up or down a queue, but it couldn't force immediate execution of another thread, couldn't suspend the current thread, and definitely couldn't do both those things simultaneously, which is what the patch does.