On Thu, 28 Aug 2025 18:00:22 -0300 Arnaldo Carvalho de Melo <arnaldo.m...@gmail.com> wrote:
> >Thus, the user stack trace will just have the offset and a hash value > >that will be match the output of the file_cache event which will have > >the path name and a build id (if one exists). > > > >Would that work? > > Probably. > > This "if it is available" question is valid, but since 2016 it's is > more of a "did developers disabled it explicitly?" The "if one exists" comment is that it's not a requirement. If none exists, it would just add a zero. > > If my "googling" isn't wrong, GNU LD defaults to generating a build > ID in ELF images since 2011 and clang's companion since 2016. > > So making it even more available than what the BPF guys did long ago > and perf piggybacked on at some point, by having it cached, on > request?, in some 20 bytes alignment hole in task_struct that would > be only used when profiling/tracing may be amenable. Would perf be interested in this hash file lookup? I know perf is reliant on user space more than ftrace is, and has a lot of work happening in user space while getting stack traces. With ftrace, there's on real user space requirement, thus a lot of the work needs to be done in the kernel. If we go with a hash to file, it's somewhat useless by itself without a way to map the hash to file/buildid. I originally started making this hash->file a file in tracefs. But then I needed to figure out how to manage the allocations. Do I add a "size" for that file and start dropping mappings when it reaches that limit. Then I may need to add a LRU algorithm to do so. I found simply having an event that wrote out the mappings was so much easier to implement. But the file_cache code could be used by perf, where perf does the same and just monitors the file_cache event. I could make the API more global than just the kernel/trace directory. -- Steve
