Using PERF_RECORD_MISC_SWITCH_OUT_PREEMPT

[tilsche]

I happened to stumble across PERF_RECORD_MISC_SWITCH_OUT_PREEMPT. It is a flag that available in the misc header for PERF_RECORD_SWITCH and PERF_RECORD_SWITCH_CPU_WIDE events. It exists since 2018 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=101592b4904ecf6b8ed2a4784d41d180319d95a1).

Now that could be useful information, but

• It is not documented in the manpage (only in the header)
• I have no idea how to map that to OTF2 in system monitoring mode.

[bertwesarg]

better ask "how should this be visualized"? from this we might figure a way to map it to OTF2

[bertwesarg]

how is the SWITCH event modeled into OTF2? If it is a function, why not use an attribute to the enter event, whether the bit is set or not. In Vampir you could then create a metric out of it (assuming its a numeric value) and visualize where preempt switches occurred (perf radar/overlay).

[tilsche]

how is the SWITCH event modeled into OTF2? If it is a function, why not use an attribute to the enter event, whether the bit is set or not. In Vampir you could then create a metric out of it (assuming its a numeric value) and visualize where preempt switches occurred (perf radar/overlay).

The "switch out" correspond to CALLING_CONTEXT_LEAVE events. I'm not really sure how this works in the process mode, but in system monitoring mode it might be difficult to find a scalable visualization - the preemption corresponds to the specific process (region). With some tracking it might be possible to derive a metric "number of currently preempted processes" to indicate over-subscription. That said I can imagine many corner cases where this tracking fails (e.g., migrations, killed threads). But also having an indication just when showing the details of the preempted process interval could already be helpful.

This might also be interesting for a current analysis we do on lo2s traces, even without any visualization.

In any case, so far it's just brainstorming.