You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
hungry-foolish
changed the title
Aggressive system call/IPC path optimization techniques
Aggressive system call/interrupt preemption path optimization techniques
Nov 6, 2018
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.
The text was updated successfully, but these errors were encountered: