Aggressive system call/interrupt preemption path optimization techniques
hungry-foolish opened this issue · 0 comments
There are some trade-offs regarding system call/interrupt kernel assembly stub optimizations. The three implementations' trade-offs are listed as below:
Save all registers on entry of both system call (SC) and interrupt preemption (IP). Current implementation.
Advantages:
Very simple, now both paths have the same or very similar code, very easy to maintain with assembly macros.
Disadvantages:
High overhead on entry of SC because we are saving unnecessary registers.
Save all registers only on the IP. Just save the callee-save registers (which callees are responsible for pushing onto the stack) on SC.
Advantages:
Just save what you need, because the user-level have already saved what is useful on the user-level
stack. In this case, there's no reason to save them again.
Disadvantages:
On both interrupt and syscall path now we have an extra branch to decide whether we need to restore all registers (when recovering from an interrupt) or just restoring callee-save registers.
Save all registers only on the IP. Just save the callee-save registers (which callees are responsible for pushing onto the stack) on SC. Rather than saving these registers to stack, we save them to the TCB directly.
Advantages:
The registers are directly saved to TCB, which speeds up preemption/thread switches a lot (now don't need to copy registers at all).
Disadvantages:
Synchronous invocation will be slowed down a bit, because we always need to switch stack pointers to the stack position upon entry of the system call handler. This is just 2 instructions, but this is the fast path, so it is not clear whether this trade-off is good or not.