irogers
Joined 6 years ago
Karma
45
Submissions
26
Member since
May 25
Recent submissions
Comment · 2 years ago
Just to advertise the perf tool has inbuilt flamegraph generation code these days (well leaning on D3.js). So `perf script report flamegraph` will convert a perf.data file into a flamegraph.html. Similarly there is `perf script report gecko` to write out the firefox profiler's json format.
Comment · 2 years ago
Agreed this is awesome, obviously sanitizers fill some of this gap currently but they aren't great with things like reference counting that RAII makes a doddle. Fwiw, here is an implementation of a runtime RAII style checking on top of leak sanitizer:
https://perf.wiki.kernel.org/index.php/Reference_Count_Check...
There's an interesting overlap with the cleanup attribute that is now appearing in the Linux kernel (by way of systemd):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Comment · 2 years ago
Somewhat related, "Data-type profiling for perf":
https://lwn.net/Articles/955709/
Comment · 2 years ago
For a collection of profilers you can also check out the Profilerpedia: https://profilerpedia.markhansen.co.nz/
Comment · 3 years ago
There are also GC techniques to make the pause shorter, for example, doing the work for the pause concurrently and then repeating it in the safepoint. The hope is that the concurrent work will turn the safepoint work into a simpler check that no work is necessary. Doubling the work may hurt GC throughput.
Comment · 3 years ago
This is awesome work and textual being able to support terminal or web (https://github.com/Textualize/textual-web) also gives hope that this can be more than a terminal app. I'm hoping that in the future features like this can be standard in Linux's perf tool, for example, Firefox profiler support was recently added as a Google summer-of-code contribution: https://perf.wiki.kernel.org/index.php/Tutorial#Firefox_Prof...
Comment · 3 years ago
Wouldn't all your kernel stacks then end up in whatever this handler is? Why not implement your approach and mail it to LKML :-)
Comment · 3 years ago
prodfiler clearly has a market. It would be interesting to see the approach as something standard in the kernel tree, perhaps it can be added to perf's synthesis, etc. There is already BPF based profiling within perf to avoid file descriptor overheads. If engineering resources are the issue then this could be a good GSoC project: https://wiki.linuxfoundation.org/gsoc/2023-gsoc-perf
Comment · 3 years ago
Allowing processes to sniff each others stacks has some fairly obvious security issues.
Comment · 3 years ago
For every running application turn DWARF data into BPF maps. Does this scale?
Comment · 3 years ago
AMD will have support in Zen4 and Linux 6.1 (which is LTS):
https://lore.kernel.org/lkml/Yz%[email protected]/
Further, precise events are fixed in Linux 6.2:
Comment · 3 years ago
DWARF bytecode is a full VM. Do compiler writers test their DWARF output? (my experience is not - especially for architectures out of the big 2 or 3) How does the kernel access the ELF file pages with the DWARF information in when in an NMI handler? You could mlock all your debug information when a program loads but the memory overhead wouldn't be nice. It is hard enough getting a build ID.
The elephant in the room btw is LBR call stacks, but they aren't exposed in the kernel/BPF yet. Userland perf has them and they recently became available on AMD.
Comment · 3 years ago
This could be a great Linux perf GSoC project. Projects and mentors are being looked for:
https://wiki.linuxfoundation.org/gsoc/2023-gsoc-perf
Comment · 3 years ago
Agner speaks about memory renaming back on Zen 2:
https://www.agner.org/forum/viewtopic.php?t=41
Intel Alderlake has performance events for tracking it:
https://github.com/intel/perfmon/blob/974c69919b2a9dfd8278cf...
But even before this you had store to load forwarding on x86. I'm not saying you have, but before inventing a performance problem it is worth spending time trying to diagnose it with thorough profiling (e.g. [1]). The Fedora frame pointer patch did a thorough performance analysis and performance will be revisited again. Unfortunately there are a lot of arm chair performance experts who haven't spent time looking into the details.
[1] https://perf.wiki.kernel.org/index.php/Top-Down_Analysis
Comment · 3 years ago
Twitter: "No need to recompile with frame pointers."
Web page: "always-on profiling powered by eBPF technology."
BPF stack traces are gathered using frame pointers:
https://github.com/torvalds/linux/blob/master/kernel/bpf/sta...
https://github.com/torvalds/linux/blob/master/arch/x86/event...