gwsystems/composite

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.