[FeatureRequest] Additional virtual event for likwid-perfctr

[ibogosavljevic]

Is your feature request related to a problem? Please describe.
Sometimes I am investigating a piece of code using marker API, and I need to check all possible events to figure out where the problem might be. There are many events that can cause problems, but that are not necessarily read from the HW counters. Examples are:
page-faults, context-switches, cpu-migrations, major-faults.

Describe the solution you'd like
I would like additional counter groups to measure this OS level events.

[TomTheBear]

Are the events provided through perf_event's software component enough? Or do you need more?

I see difficulties for the accessdaemon/direct access mode case because we want counts for all CPU cores we are running on. This would include also other applications, not just the one wrapped with LIKWID. Not sure whether perf_event can do that for us. Reading procfs for all applications is not feasible.

The current structure of LIKWID requires to add this component to each architecture manually. There is no way to add it once for all. This is just some copy&paste thing. I'm planning a redesign of the logic. With this, it would a single change.

I'm quite busy with support for new hardware, so do you want to try implementing it yourself?

[ibogosavljevic]

Hi Tom!

I could try doing it, I use LIKWID a lot and it is a very useful piece of software to me. Can you give me some estimate how much time would I need?

[TomTheBear]

It's difficult for me to estimate the coding time of others because I know the code and where to get internal information from. But it's not a extensive effort like the Uncore of some server-class chip or some complete accelerator support.

Basically, you need some self contained interface with something like:

• init(): initialize data structures
• setup(EventSet): program the event set.
• start() and stop(): Get current value and start/stop counting
• freeze() & unfreeze(): stop/keep counting without destroying counts
• read(): Read the counts
• finalize(): tear down everything. Take care if counters are running.

(Start and stop are used for common profiling while (un)freeze and read in markerAPI case)

The src/includes/perfmon_perfevent.h file contains an example how to use perf_event. You can use the code as basis for your attempt. In likwid-perfctr, there is already a possibility to export the PID of the wrapped application. You can use that to restrict the measurements to this PID (and maybe its child processes).

All architecture files (src/includes/perfmon_*.h) contain a big switch case statement. You have to add our functions there. Define a separate type (SOFTWARE or similar, see src/includes/registers_types.h). You have to add new counters and events (search for the GENERIC_EVENT code in src/perfmon.c for a global way to add them). LIKWID needs some kind of separate counter(s) for the OS events because counters are its variables when deriving metrics. You probably need some kind of lock so that the software counts are read only by one of the participating hardware threads. You can either handle the lock internally in your files or create a new lock like the socket_lock.

You can reach out to me at anytime here or in a matrix chat.