Dropping a marker for reference in analysis?

[shoffmeister]

With my perf no longer acting up, I now wonder whether there is a way to drop markers into the trace for later reference.

A marker would be much like an anonymous bookmark (numbered?) set by a human as in "I am about to do something now".

My first ever use case for magic-trace (perf) is trying to figure out why the kwin_wayland rendering process on my (new) Nvidia + Intel mixed GPU laptop consumes massive CPU when drawing in a very specific configuration, getting totally laggy on presentation. Talk about ambition...

For that, I want to

• start magic-trace
• wiggle the mouse on screen number 1 (totally fine)
• move the mouse to screen number 2
• set marker / bookmark number 1
• wiggle the mouse on screen number 2 (which is enough to lag like ... eeew)
• set marker / bookmark number 2
• move the mouse back to safe haven screen 1
• stop magic-trace
• load all 110 MB of data for analysis (it's really only 110 MB for 7 secs of recording, I am surprised)

When launching analysis, I want to focus on everything between bookmarks 1 and 2, because it's laggy, something really burns CPU according to htop, producing heat, as if we didn't have enough of a problem with that already...

Clearly the human being in me could count twenty-one, twenty-two, ..., record all of that, cross-ref all of that - but my poor poor mental (over)load! Plus, communicating "go look at anything between b1 and b2" is much more robust than directing by unreliable "perceived" timestamps.

Is there any means to accomplish the above? A signal I could send to magic-trace? (kill ALRM? TRAP? USR1? USR2?)

Hm. Perhaps this is a perfetto question?

[shoffmeister]

"Annotation", I believe is the term I was looking for, as in

... at the time of collecting the data?

[Xyene]

puts on Wayland developer hat

This sounds like failing to do cross-device dmabuf exports/imports, and having to fall back to GPU readback and CPU copies. If this is Plasma 5.23+ I think it should be using wlroots for its backend, in which case you could ask in IRC (#sway-devel on Libera) how to determine if this in fact happening.

takes Wayland developer hat off, puts on magic-trace developer hat

Silly idea: send an ignored signal (e.g. SIGWINCH) to kwin, and trace with -multi-thread. I think you should see some callstacks corresponding to your sending of the signal. Then you can open up the trace in Perfetto, use the search bar to find the signal handlers, and then plant some flags around them. If it is dmabuf-related, then I'd expect -trace-include-kernel to be helpful too.

Separately, it doesn't seem unreasonable to have magic-trace respond to e.g. SIGUSR1 by tracking when it occurred, and adding a marker. We already maintain state like this for when breakpoints are hit. Patches welcome for this!

[shoffmeister]

Dear Wayland developer ;) I concur. One trace attempt got me seeing plenty of memmove, and with the latest released proprietary Nvidia drivers (510.x) in the game, lack of dmabuf (because of GPL) is a hot candidate. My working hypothesis is that there is massive buffer copying going on (from Intel to Nvidia, and that just for presentation), to an extent (size and count) which would seem excessive. This would possibly be caused by the laptop screen (on Intel) being "plain" 3K, the target 4K screen (on Nvidia) being HDR-enabled, and there being some 8bpc vs 10bpc ... things ... going on. And while I throw around all these buzzwords, I have to admit that I have no real idea what I am talking about beyond just those buzzwords.

With respect to magic-trace, I am struggling to get reproducible, meaningful traces. I have yet to root cause that; I suspect it's a combination of me still being in explorative mode with the tooling and the tooling itself doing unexpected things. The good thing is that the KDE Wayland compositor, which is where all the CPU is burnt, runs as an unprivileged user, so I am less scared to throw things at it (X runs as root, also burns CPU).

Many thanks for the ideas on "stamping" some markers into the trace; I'll try that.

I'll also look into state management and whether I would be able to extend that.