- slides: https://wiki.ubuntu.com/Specs/M/ARMDebuggingWithOprofileAndPerf
- === Discussion ===
- * platform device infrastructure used for performance monitor unit (PMU) - simple to new, but not typically present for new BSPs --- BSP maintainers need to add it.
- * Probably doesn't work in QEMU.
- * Hardware typically has many counters all over the system -- not currently clear how to export all of this through perfevents. The various parts of the hardware might
- be asynchronous in terms of measuring the events and hence tying it to a frame of reference is a hard problem.
- * What are the usecases for the other counters on the system ?
- * L2 cache is probably the easiest "uncore" event to handle.
- * "uncore" events not a solved problem on any architecture yet -- easy to put in the kernel, but the tools don't really understand non-CPU-specific events yet.
- * may be able to include data about event sources in sysfs
- * kiko: graphing performance profile data over time could be useful
- * linux-tools (see http://packages.ubuntu.com/lucid/linux-tools) is not currently built for ARM, but ought to be straightforward.
- * Tools are in the kernel tree - packaged specific to a kernel version
- * Restrict number of running processes and create a stable "environment"
- GUIs and frontends
- * The only "GUI" is an SVG generation backend - SVGs tend to be impossible to open if profiling has been run for sufficient time (too much data?)
- * "perf top" command (from linux-tools?) provides real-time view of profiling data on the console.
- * "perf record <command>" runs <command>, capturing profiling data
- * "perf report" reports results
- * "perf annotate" produces source, annotated with profiling data
- * "perf list" lists the event types supported by the system
- * "perf stat" gives overall statistics for a profiling run
- * Tools may not understand getting symbols from ddebs yet (separated debug symbol information packages in Ubuntu)
- * ddebs are not generated for all packages yet, not generated in all archives (e.g., Debian) and not generated for PPAs right now. It would be useful to enable ddeb generation more widely.
- * A converter tools may exist in kcachegrind to convert profiling data.
- Portability
- * Userspace tools need to understand what event types exist per platform
- * May not be feasible for the kernel to export this database to userspace --- it may be large for some platforms, including ARM.
- * These tools are not so good at displaying multiple event types simultaneously in a useful way -- an integrated GUI would be nice, but doesn't exist yet.
- Streaming
- * Could be useful to stream perf data off a client machine to be processed remotely at a server.
- * Looks feasible, but not implemented yet?
- * Data has headers which need to be parsed up-front, but the main data is a stream and can be processed incrementally over time.
- * Should be possible to extract ddebs on the server (which may be a foreign architecture), but this may not work out of the box. Cross-/multi-arch binutils would also be needed on the server.
- === Action Items ===
- * Will Deacon: update oprofile userspace
- * Will Deacon: create / provide link to wiki page documenting how to enable perf event support for a new platform.
- * Will Deacon: if a vmlinux file needed to profile inside the kernel?
- * Loic Minier: Enable linux-tools building for armel. Packages may be needed per-platform (i.e., per kernel tree)
- * Dave Martin: Teach the perf userspace tools how to get symbol information out of ddebs, not necessarily on /usr/lib/debug (for cross-arch support).
- * scottb: Work out how to get cross-profiling to work (getting the right binaries and debug symbol archives onto the server). Use sshfs to access the target's filesystem? (but may be a space issue)