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

Optimize the TLB considering the Hypervisor extension #60

Open
edubart opened this issue May 29, 2023 · 0 comments
Open

Optimize the TLB considering the Hypervisor extension #60

edubart opened this issue May 29, 2023 · 0 comments
Labels
optimization Optimization

Comments

@edubart
Copy link
Contributor

edubart commented May 29, 2023

Context

The Hypervisor extension (issue #44) introduces new address translation semantics that the current TLB was not designed for. There are two situations that we need to investigate for possible optimizations.

  1. Hypervisor introduces new hypervisor specific load/store instructions that performs virtual address translation using custom access modes (privilege mode + virtual mode). The way the current TLB is designed makes it impossible to use the TLB in these instructions, because the TLB is designed to support only the current access mode, therefore these new instructions have to always use the slow address translation path, this is bad for performance. Furthermore having a TLB per access mode gives the opportunity to decrease TLB shootdowns in access mode switches, however this may not be that promising, because the kernel scheduler already minimizes the amount of access mode switches to make good use of the CPU, so the performance gains of this may be negligible.

  2. Hypervisor introduces a two-stage address translation, we could have a TLB for each stage, but it's not clear if this would pay off, it deserves some investigation. At first, this is not a big issue because the current TLB is still used for whole two-stage process, therefore a TLB only for the second stage of the address translation would only speed-up the second stage translation after a miss of the first stage, and optimizing miss code path may not be promising.

Possible solutions

  1. First we need to investigate how often hypervisor load/store is really used, otherwise this optimization will not give us meaningful benefits. If hypervisor load/store are used very often, we could make a TLB per access mode, there are 5 possible access modes (U-mode, M-mode, HS-mode, VU-mode, VS-mode)

  2. First we need to investigate how often the miss path of the two-stage is hit, otherwise this optimization will not pay off. We could duplicate the TLB, to have one for the whole two-stage process, and a second TLB only for the second stage.

@edubart edubart added the optimization Optimization label May 29, 2023
@edubart edubart self-assigned this May 29, 2023
@edubart edubart changed the title Optimize TLB taking consideration of Hypervisor extension Optimize the TLB considering the Hypervisor May 29, 2023
@edubart edubart changed the title Optimize the TLB considering the Hypervisor Optimize the TLB considering the Hypervisor extension May 29, 2023
@edubart edubart removed their assignment Jun 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optimization Optimization
Projects
Status: Todo
Development

No branches or pull requests

1 participant