Support bigger traces at lower resolution

[lpw25]

My understanding is that one of the main blockers preventing taking traces for longer time periods is that perfetto can't handle the size of traces that it produces. I would happily settle for longer traces which only showed function calls that took more than a certain amount of time -- to give a high-level view of where the time was spent. Combined with some option to filter a trace down to a given time range this should allow for exploring large traces reasonably ergonomically.

[Xyene]

If we decrease the timing resolution in software, we can also request lower timing resolution from the hardware, for lower overhead.

Refs:

• magic-trace/src/perf_tool_backend.ml

  Lines 52 to 61 in e9d5d26

  	if Perf_capabilities.(do_intersect capabilities configurable_psb_period)
  	then
  	(* Using Intel Processor Trace with the highest possible granularity. *)
  	"--event=intel_pt/cyc=1,cyc_thresh=1,mtc_period=0/u"
  	else (
  	Core.eprintf
  	"[Warning: This machine has an older generation processor, timing granularity \
  	will be ~1us instead of ~10ns. Consider using a newer machine.]\n\
  	%!";
  	"--event=intel_pt//u")

• http://halobates.de/blog/p/432

[lpw25]

That seems worth supporting too. Although for my use case I'd like to take a single trace, view it in its entirety at a low resolution, and then view subsections of the trace at high resolution once I had identified which parts where interesting.

[Xyene]

Fuchsia supports inserting binary blobs to the trace file: https://fuchsia.dev/fuchsia-src/reference/tracing/trace-format#blob-record

We could include the perf.data and associated files there (as a tarball?), I think, to allow later processing.

[ahh]

I want the blob (as @Xyene knows) for general debuggability so I think that's a great feature in and of itself. The idea of then being able to recursively reprocess the output to something filtered for Perfetto friendliness sounds fantastic (if hilarious.)