Discoverability of perf event types

[adamtassier]

Is your feature request related to a problem? Please describe.
Hotspot was my first introduction to using perf. It took a me an (embarrassingly) long time to figure out there's other events than just 'cycles' and how good this is all integrated in hotspot.

Neither does the README contain any examples of using other events nor screenshots of the UI with multiple events enabled.

Describe the solution you'd like
An addition to the README's 'Using' section that demonstrates using multiple perf events, a list of some useful ones and a link to more information about perf events.

Maybe it could be integrated in the 'record' UI as well? I was thinking about adding some checkboxes next to the 'Event Type(s)' field containing the pre-defined events from perf list?

Describe alternatives you've considered
Reading the perf manual sooner :)

Additional context
UI mock:

[milianw]

Thanks for raising this topic, you are not wrong, but I do think this topic is way more complicated than you might assume ;-) I.e. we definitely don't want to do the naive sampling on multiple PMUs as that can lead to too much noise. Instead, leader sampling should be used, but that is somewhat flaky too in my testing (it sometimes breaks in kernel updates). Still, that's what should be done by default I think.

https://www.man7.org/linux/man-pages/man1/perf-list.1.html#LEADER_SAMPLING

Also hard coding an event in the way you suggest in your mockup will lead to failures in contexts where no PMU is available but the timer based fallback would still work. This is why not doing anything by default and letting the user write the more complex requests in the "event type(s)" edit is better imo. Maybe we should include some common examples as predefined values in the drop down instead?

anyhow, patches welcome!

[adamtassier]

Thanks for raising this topic, you are not wrong, but I do think this topic is way more complicated than you might assume ;-)

I feared as much :)

I.e. we definitely don't want to do the naive sampling on multiple PMUs as that can lead to too much noise.

Sorry I don't know if I'm understanding you 100% correctly, are you saying that:
a) Different events map to different PMU's and we shouldn't mix them?
b) Different events map to the same PMU but they can interfere?
c) Theres often too few PMU's to capture multiple events?
d) something else completely?

I was under the impression that at least a few hardware performance counters were available. Seems I was wrong as checking on my home PC cpuid tells me I have none... (ryzen 3600).

Also hard coding an event in the way you suggest in your mockup will lead to failures in contexts where no PMU is available...
Maybe we should include some common examples as predefined values in the drop down instead?

Certainly didn't want to suggest just hardcoding them. I was thinking about adding them to the dropdown as well. It's just that speaking from experience, I only discovered today that it was in fact a dropdown (after 6months of intensive usage of hotspot)

anyhow, patches welcome!

I'll try to create a PR with a small section added to the readme clarifying event usage and maybe add some defaults to the dropdown (and maybe hack a little on the UI in the meantime) .