perf: Linux Profiling GSoC 2022

Google Summer of Code Project ideas for perf, the Linux profiling subsystem.

(Main Linux foundation GSoC 2022 page)

perf has two components:

1. kernel support for performance counters, performance monitoring units and tracing;
2. a tool for accessing the kernel provided data, recording and visualizing it.

perf has had various enhancements such as support for BPF.

Maintainers: Peter Zijlstra <peterz at infradead.org>, Ingo Molnar <mingo at redhat.com>, Arnaldo Carvalho de Melo <acme at kernel.org>

Mailing list: linux-perf-users at vger.kernel.org

IRC: #perf on irc.oftc.net

Code Licenses: mostly GPLv2

Wiki: https://perf.wiki.kernel.org/

Mentor contacts: Ian Rogers <irogers+gsoc22 at google dot com>, Namhyung Kim <namhyung at kernel.org>

If you have your own ideas for how tracing and profiling can be improved in the Linux kernel and perf tool then these are welcomed. Some areas that have been brought up in the last year are better support for more programming languages, better packaging in Linux distributions and new profiling commands like function latency measuring.

perf trace provides an strace like ability using perf APIs. By avoiding ptrace APIs, perf trace can even trace itself. The filename for an open system call is fairly boring encoded as a pointer. To get the actual filename the program is sending to the kernel requires information not captured in a perf event, and so libaudit is currently used. Libaudit adds code in the kernel on a number of system calls but not all - for example, there is no libaudit on the perf_event_open system call. A different technique for intercepting system calls and sending information to user land is BPF. This project will look to add a variant to perf trace where instead of getting filenames for system calls using libaudit, it will do so with BPF programs that perf can install in the kernel when the program starts up. The large number of system calls means this is a large challenge.

Currently the perf report command will process an entire perf.data file before providing a visualization. This can be slow for large perf.data files. In contrast, the perf top command will gather data in the background while providing a visualization. This project will look to break apart perf report so that processing is performed on a background thread with the visualization periodically refreshing.

Perf has different user interfaces:

• stdio - the most basic UI that can use a pager like less,
• tui - based on slang,
• gtk - uses the gtk2 user interface. This option isn't enabled by default at build time.

This project will look to improve the user interface experience with perf, for example, by upgrading the gtk2 code to use gtk4. The addition of other user interfaces would be an option for this project.

The perf data command allows a perf.data file to be converted to other file formats, however, currently only CTF is supported. This project will look to add support for other file formats such as Firefox's Gecko profile format or Chrome's trace event format. By supporting conversion to these file formats visualization tools will be able to show a recorded perf.data file.

Large parts of the perf command are single threaded. As CPU core counts increase, this means that programming events can be slow and the command in general can be slower that it needs to be. This project will look to provide parallel approaches to processing perf data structures such as evlist so that more concurrency happens within the perf command. This work will build upon that donee by Riccardo Mancini in GSoC 2021.