Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aggressive system call/interrupt preemption path optimization techniques #379

Open
hungry-foolish opened this issue Nov 6, 2018 · 0 comments

Comments

@hungry-foolish
Copy link
Contributor

hungry-foolish commented 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.

@hungry-foolish hungry-foolish changed the title Aggressive system call/IPC path optimization techniques Aggressive system call/interrupt preemption path optimization techniques Nov 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant