User Tools

Site Tools


gsoc:2023-gsoc-perf

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
gsoc:2023-gsoc-perf [2023/01/16 13:53]
till created
gsoc:2023-gsoc-perf [2023/01/25 00:53] (current)
irogers Add qualities of a good proposal.
Line 27: Line 27:
 Mentor contacts: [[https://​sites.google.com/​site/​rogersemail/​home|Ian Rogers]] <​irogers+gsoc22 at google dot com>, Namhyung Kim <​namhyung at kernel.org>​ Mentor contacts: [[https://​sites.google.com/​site/​rogersemail/​home|Ian Rogers]] <​irogers+gsoc22 at google dot com>, Namhyung Kim <​namhyung at kernel.org>​
  
-===== Project Proposals ​=====+===== Qualities of a good proposal ​=====
  
-**To be updated**+  ​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 ==== ==== 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]], [[https://​lore.kernel.org/​linux-perf-users/​CAP-5=fW7La9ZNv8Z6LHRRNXne4+dWK6dR1ye2P=zETFELtK=fg@mail.gmail.com/​|better packaging in Linux distributions]] and [[https://​lore.kernel.org/​all/​20211129231830.1117781-1-namhyung@kernel.org/​|new profiling commands like function latency measuring]].+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 ==== ==== User Interface ====
Line 39: Line 43:
 === Improved perf trace === === 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 libaudit is currently used. Libaudit adds code in the kernel on 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.+''​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 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 === === Interactive perf report ===
Line 52: Line 56:
   * gtk - uses the gtk2 user interface. This option isn't enabled by default at build time.   * 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.+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 ==== ==== Perf data converter ====
Line 60: Line 64:
 ==== Scalability and speed ==== ==== 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 donee by Riccardo Mancini [[https://​lore.kernel.org/​linux-perf-users/​3c4f8dd64d07373d876990ceb16e469b4029363f.camel@gmail.com/​|in GSoC 2021]].+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]].
gsoc/2023-gsoc-perf.1673877236.txt.gz · Last modified: 2023/01/16 13:53 by till