3 ms·
You basically have kernel threads, in which you can have more than one user space threads. The advantage is that you can context switch between threads without
by ActorNightly 6y ago
You basically have kernel threads, in which you can have more than one user space threads. The advantage is that you can context switch between threads without having to syscall, which speeds up things substantially.
- 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.