irogers · HackerTrans

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.

irogers

há 2 anosdiscuss

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...

irogers

há 2 anosdiscuss

Somewhat related, "Data-type profiling for perf": https://lwn.net/Articles/955709/

irogers

há 2 anosdiscuss

For a collection of profilers you can also check out the Profilerpedia: https://profilerpedia.markhansen.co.nz/

irogers

há 3 anosdiscuss

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.

irogers

há 3 anosdiscuss

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...

irogers

há 3 anosdiscuss

Wouldn't all your kernel stacks then end up in whatever this handler is? Why not implement your approach and mail it to LKML :-)

irogers

há 3 anosdiscuss

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

irogers

há 3 anosdiscuss

Allowing processes to sniff each others stacks has some fairly obvious security issues.

irogers

há 3 anosdiscuss

For every running application turn DWARF data into BPF maps. Does this scale?

irogers

há 3 anosdiscuss

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:

https://lore.kernel.org/lkml/Y5eQeR2tpZ%[email protected]/

irogers

há 3 anosdiscuss

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.

irogers

há 3 anosdiscuss

This could be a great Linux perf GSoC project. Projects and mentors are being looked for: https://wiki.linuxfoundation.org/gsoc/2023-gsoc-perf

irogers

há 3 anosdiscuss

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

irogers

há 3 anosdiscuss

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...

irogers

há 3 anosdiscuss

This seems relevant:

Future of Memory Safety Challenges and Recommendations https://advocacy.consumerreports.org/wp-content/uploads/2023...

""" Case Studies 1. The Python cryptographic authority is one of the most widely used cryptography libraries in the Python ecosystem. Many of the tools are largely built on OpenSSL. The popular cryptography library is written in C. About two years ago, the maintainers started the process of migrating some of their dependence on OpenSSL away from that to their own Rust code, particularly starting with areas around certificate parsing and parsing of other structures. These are some of the most classical places to find memory safety vulnerabilities in C libraries, and they wanted to mitigate the risk that they were having by relying on OpenSSL.

Another benefit was getting huge performance improvements, because the greater safety guarantees they were getting from the language allowed them to be more aggressive in doing things like not copying memory. Specifically, the safety guarantees of Rust mean that one can easily represent structures like X.509 certificates as an array of bytes, and then a parsed structure containing pointers into the original array. ... """

comments