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

RFC-16: New capability for the PMU #22

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

RFC-16: New capability for the PMU #22

wants to merge 2 commits into from

Conversation

lsf37
Copy link
Member

@lsf37 lsf37 commented Jun 14, 2024

See https://sel4.atlassian.net/browse/RFC-16

Signed-off-by: Gerwin Klein <gerwin.klein@proofcraft.systems>
Ivan-Velickovic added a commit to seL4/microkit that referenced this pull request Jul 3, 2024
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>
Ivan-Velickovic added a commit to seL4/microkit that referenced this pull request Jul 3, 2024
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>
Ivan-Velickovic added a commit to seL4/microkit that referenced this pull request Jul 3, 2024
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>
Ivan-Velickovic added a commit to seL4/microkit that referenced this pull request Jul 9, 2024
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>
Ivan-Velickovic added a commit to Ivan-Velickovic/microkit that referenced this pull request Jul 9, 2024
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>
Ivan-Velickovic added a commit to Ivan-Velickovic/microkit that referenced this pull request Jul 9, 2024
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>
Ivan-Velickovic added a commit to Ivan-Velickovic/microkit that referenced this pull request Jul 9, 2024
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>
@lsf37
Copy link
Member Author

lsf37 commented Aug 4, 2024

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.

@Kswin01
Copy link

Kswin01 commented Aug 21, 2024

@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)?

@Indanz
Copy link

Indanz commented Aug 21, 2024

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 KernelArmExportPMUUser is probably sufficient on ARM. It would be nice if it could be enabled and disabled at runtime via a capability, but not sure if more is needed.

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.

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

Successfully merging this pull request may close these issues.

4 participants