-
Notifications
You must be signed in to change notification settings - Fork 3
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
RFC-16: New capability for the PMU #22
base: main
Are you sure you want to change the base?
Conversation
See https://sel4.atlassian.net/browse/RFC-16 Signed-off-by: Gerwin Klein <gerwin.klein@proofcraft.systems>
This patch adds a new configuration for each platform called 'benchmark'. The purpose of this is to enable Microkit systems to leverage the benchmark configuration of seL4 that tracks things like kernel entries and CPU utilisation. This also exports the PMU to user-space. This is not ideal, which is why [RFC-16](seL4/rfcs#22) exists. However, we need to be able to benchmarking for projects like the seL4 Device Driver Framework in the meantime. It may take a while to get the RFC approved and implemented which is why we are adding this 'temporary' configuration. Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
This patch adds a new configuration for each platform called 'benchmark'. The purpose of this is to enable Microkit systems to leverage the benchmark configuration of seL4 that tracks things like kernel entries and CPU utilisation. This also exports the PMU to user-space. This is not ideal, which is why [RFC-16](seL4/rfcs#22) exists. However, we need to be able to do benchmarking for projects like the seL4 Device Driver Framework in the meantime. It may take a while to get the RFC approved and implemented which is why we are adding this 'temporary' configuration. Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
This patch adds a new configuration for each platform called 'benchmark'. The purpose of this is to enable Microkit systems to leverage the benchmark configuration of seL4 that tracks things like kernel entries and CPU utilisation. This also exports the PMU to user-space. This is not ideal, which is why [RFC-16](seL4/rfcs#22) exists. However, we need to be able to do benchmarking for projects like the seL4 Device Driver Framework in the meantime. It may take a while to get the RFC approved and implemented which is why we are adding this 'temporary' configuration. Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
This patch adds a new configuration for each platform called 'benchmark'. The purpose of this is to enable Microkit systems to leverage the benchmark configuration of seL4 that tracks things like kernel entries and CPU utilisation. This also exports the PMU to user-space. This is not ideal, which is why [RFC-16](seL4/rfcs#22) exists. However, we need to be able to do benchmarking for projects like the seL4 Device Driver Framework in the meantime. It may take a while to get the RFC approved and implemented which is why we are adding this 'temporary' configuration. Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
This patch adds a new configuration for each platform called 'benchmark'. The purpose of this is to enable Microkit systems to leverage the benchmark configuration of seL4 that tracks things like kernel entries and CPU utilisation. This also exports the PMU to user-space. This is not ideal, which is why [RFC-16](seL4/rfcs#22) exists. However, we need to be able to do benchmarking for projects like the seL4 Device Driver Framework in the meantime. It may take a while to get the RFC approved and implemented which is why we are adding this 'temporary' configuration. Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
This patch adds a new configuration for each platform called 'benchmark'. The purpose of this is to enable Microkit systems to leverage the benchmark configuration of seL4 that tracks things like kernel entries and CPU utilisation. This also exports the PMU to user-space. This is not ideal, which is why [RFC-16](seL4/rfcs#22) exists. However, we need to be able to do benchmarking for projects like the seL4 Device Driver Framework in the meantime. It may take a while to get the RFC approved and implemented which is why we are adding this 'temporary' configuration. Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
This patch adds a new configuration for each platform called 'benchmark'. The purpose of this is to enable Microkit systems to leverage the benchmark configuration of seL4 that tracks things like kernel entries and CPU utilisation. This also exports the PMU to user-space. This is not ideal, which is why [RFC-16](seL4/rfcs#22) exists. However, we need to be able to do benchmarking for projects like the seL4 Device Driver Framework in the meantime. It may take a while to get the RFC approved and implemented which is why we are adding this 'temporary' configuration. Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
Status update from 2024-07-25 TSC meeting: awaiting update from Gernot; likely to be split into two RFCs, one for global one for thread-local PMU access. |
@Indanz Hi Indan, I'm finally getting back around to working on the RFC and had a question about a comment you made about providing a system call interface for accessing the PMU not being useful for timing sensitive register accesses. What would be some examples of these applications, where ~1000 cycles of delay would be noticeably detrimental(Outside of profiling)? |
The whole point of Performance Monitor Units is profiling, so outside of profiling: None. Using PMU for thermal and energy management is an unusual use case. That said, for production having profiling on is unusual too and for benchmarking enabling Your proposed API seems very tailored to your needs, but it's unclear whether it's the best way to give access to the PMU in general, nor whether using PMU is the best solution for your problem. It's also unclear how it will interact with virtualisation. On the upside, a syscall approach avoids any context switch slowdowns. But if doing a syscall based solution, I would prefer to keep it as simple as possible: Limit it to reading and writing PMU registers, and do the rest in user space if possible. PMU gives timing info about all processes running, so making it fine grained on an event type basis via badging doesn't add security. Managing events can also be done in user space, the added value for doing it in the kernel is low. Other than CPU utilisation, what are you using the PMU for? Total CPU utilisation you could collect with a low priority task instead of PMU. Does your platform have thermal PMU events? It seems like it does and that's why you want badging, so you can have critical thermal PMU events mixed with performance profiling. |
Original Jira issue and discussion