> You still might have LBR buffers deep enough for your purposes, I think > that's worth checking. They have been around for much longer (on > Intel). We've been using LBR opportunistically for a while if available to augment frame pointer based stacks. It turns out to be quite helpful at the lowest levels of the stacktrace where it can help to work around the lack of frame pointers in base system libraries or libraries using inline assembly. 32 entries are not sufficient to capture all of our stacktraces though so using only LBR is not sufficient for our profiling. Currently we augment the frame pointer stacks with LBR data in userspace but I've asked Andrii to look into doing this augmentation directly in the kernel so that everyone can benefit from it. I think it might help with cases such as the glibc string functions as well (but you probably know more about that than I do). > Does your use case actually involve high-frequency time-based profiling, > or is it more about being able to get the data at all, and process it > further using BPF? Yes, we're doing high-frequency sampling profiling using the perf subsystem (see the proposal for a detailed description). We attach BPF programs to perf events for some minimal post processing before storing the data. Cheers, Daan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
