====== perf: Linux Profiling GSoC 2023 ====== Google Summer of Code Project ideas for perf, the Linux profiling subsystem. [[gsoc:google-summer-code-2023|(Main Linux foundation GSoC 2023 page)]] ===== What is perf? ===== perf has two components: - kernel support for performance counters, performance monitoring units and tracing; - a tool for accessing the kernel provided data, recording and visualizing it. perf has had various enhancements such as support for BPF. ===== Perf community ===== [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS|Maintainers]]: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo Mailing list: [[https://www.spinics.net/lists/linux-perf-users/|linux-perf-users at vger.kernel.org]] IRC: #perf on irc.oftc.net Code Licenses: mostly GPLv2 Wiki: [[https://perf.wiki.kernel.org/index.php/Main_Page|https://perf.wiki.kernel.org/]] Mentor contacts: [[https://sites.google.com/site/rogersemail/home|Ian Rogers]] , Namhyung Kim ===== Qualities of a good proposal ===== * Contributor has engaged with the community by, for example, writing a patch, contributing to the wiki, or reporting a bug. * The time plan for the project is clear and mentions how other commitments the contributor has will be managed alongside the project. * There is sufficient detail in the proposal that it is clear the contributor and mentors will be able to get the project done. ===== Project Proposals ===== ==== Bring your open proposal ==== 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 [[https://lore.kernel.org/linux-perf-users/87o85ftc3p.fsf@smart-cactus.org/|better support for more programming languages]] and [[https://lore.kernel.org/all/20211129231830.1117781-1-namhyung@kernel.org/|new profiling commands like function latency measuring]]. ==== User Interface ==== === Improved perf trace === ''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 BPF and a list of argument types is maintained. This project will look to update the BPF code in ''perf trace'' so that it is shipped as a skeleton built into the actual perf application, rather than as a file on the command line. Further, the project will look to automate the task of decorating syscall arguments using the BPF Type Format (BTF). === Interactive perf report === 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. === Adding or improving graphical toolkit support === Perf has different user interfaces: * stdio - the most basic UI that can use a pager like ''less'', * tui - based on [[http://www.jedsoft.org/slang/|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 using a new user interface library like [[https://www.textualize.io/|Textualize]]. The addition of other user interfaces would be an option for this project. ==== Perf data converter ==== 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 [[https://github.com/firefox-devtools/profiler/blob/main/docs-developer/gecko-profile-format.md|Gecko profile format]] or Chrome's [[https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview|trace event format]]. By supporting conversion to these file formats visualization tools will be able to show a recorded perf.data file. ==== Scalability and speed ==== 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 done by Riccardo Mancini [[https://lore.kernel.org/linux-perf-users/3c4f8dd64d07373d876990ceb16e469b4029363f.camel@gmail.com/|in GSoC 2021]].