Can magic-trace be used to get perf-report like output?

[smarr]

magic-trace sounds great in terms of accuracy.
Would it be possible to get a simple perf report out of it?

For context, I am currently using a setup that automatically collects perf reports for benchmarks we run, and integrates the output in my ReBenchDB benchmark reports. Below some links and an example.

Since we use it for every push, and keep the data around, I try to minimize what is stored, and basically keep lightly manipulated perf report output in a database.
Though, the longer I work with this, it seems the perf accuracy isn't great, and too often misleading.
On the positive side, it gives a good overview, and first indication of what is going on.
So, yeah, I was wondering whether using magic-trace for the extra accuracy would be an option, but having an abbreviated pref-report-like representation would be a must for my use case.

Any pointers or suggestions would be appreciated.

Thank you!
Stefan

ReBenchDB Example for Context

An example benchmark report can be found here. Look for one of the stop watch buttons, and it will load the profile info.

[cgaebel]

Give magic-trace a -working-directory flag and it will output a perf.data file into that directory. Then, cd to that directory and run perf report.

I think the only useful data that it shows is PSB events, which are lower granularity than "every branch" that magic-trace records by default. Play around with perf reports command line flags and let us know if you manage to get anything particularly useful out of it.

[smarr]

Thanks. Using -working-directory I indeed get the normal perf report from that using perf report -g graph --no-children --stdio --input=perf.data.

Though, the output suggests it doesn't actually use the Processor Trace data.
I am saying that because the output says first that it captured and wrote the perf.data file with a specific size. Only afterwards, it says "Decoding, this takes a while...".

In the magic-trace.org interface, you got a "Slice" tab, for which you give ms wall duration per function. Is this based on the PT-based data, and reflects the increase precision?

If so, would there be a way to extract that data in a way that I can see the actual time spent in each function, and the call stacks that lead to it?

[Xyene]

Though, the output suggests it doesn't actually use the Processor Trace data.

The "Decoding, this takes a while..." message comes from magic-trace itself, not perf. This is the step where we walk all IPT events and reconstruct callstacks in trace_writer.ml. All IPT events are in the perf.data, and you can see their raw form through perf report -D perf.data.

To see the actual data magic-trace ingests, run

perf script -i perf.data --ns --itrace=be -F pid,tid,time,flags,ip,addr,sym,symoff

(Read through https://halobates.de/blog/p/329 to see how you could generate flamegraphs from that information, if you want.)

In the magic-trace.org interface, you got a "Slice" tab, for which you give ms wall duration per function. Is this based on the PT-based data, and reflects the increase precision?

Yes.

If so, would there be a way to extract that data in a way that I can see the actual time spent in each function, and the call stacks that lead to it?

That table is constructed by Perfetto at runtime (in-browser) from the Fuchsia trace file magic-trace generates, but the trace file itself ~straightforwardly contains that information. You should be able to read it:

• from the binary format, https://fuchsia.dev/fuchsia-src/reference/tracing/trace-format
• or by converting it to JSON, https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/docs/development/tracing/tutorial/converting-visualizing-a-trace.md

[smarr]

@Xyene thank you!

Before I go on the endeavor of parsing the trace file or JSON, just to be sure, the perf.data file is just at the normal level of perf?

So, if I want the better precision, parsing the trace is the way to go?

[Xyene]

You can always parse the perf.data yourself (either from its text form from perf script, or perf script --dlfilter). See https://perf.wiki.kernel.org/index.php/Perf_tools_support_for_Intel%C2%AE_Processor_Trace

The "value add" of magic-trace over plain perf is just:

• the (pretty gnarly) logic for reconstructing callstacks
• the support for perf.map files for JITed languages (perf should support these, but for some reason doesn't when decoding IPT traces)
• the easy-to-use breakpoint snapshots
• the UI

If you don't need these, or are willing to reimplement the ones you care about, you can parse the perf file yourself and eschew usage of magic-trace.