On Sat, May 4, 2024 at 10:26 PM Ian Rogers <irogers@xxxxxxxxxx> wrote: > > On Fri, May 3, 2024 at 5:30 PM Andrii Nakryiko <andrii@xxxxxxxxxx> wrote: > > > > Implement binary ioctl()-based interface to /proc/<pid>/maps file to allow > > applications to query VMA information more efficiently than through textual > > processing of /proc/<pid>/maps contents. See patch #2 for the context, > > justification, and nuances of the API design. > > > > Patch #1 is a refactoring to keep VMA name logic determination in one place. > > Patch #2 is the meat of kernel-side API. > > Patch #3 just syncs UAPI header (linux/fs.h) into tools/include. > > Patch #4 adjusts BPF selftests logic that currently parses /proc/<pid>/maps to > > optionally use this new ioctl()-based API, if supported. > > Patch #5 implements a simple C tool to demonstrate intended efficient use (for > > both textual and binary interfaces) and allows benchmarking them. Patch itself > > also has performance numbers of a test based on one of the medium-sized > > internal applications taken from production. > > > > This patch set was based on top of next-20240503 tag in linux-next tree. > > Not sure what should be the target tree for this, I'd appreciate any guidance, > > thank you! > > > > Andrii Nakryiko (5): > > fs/procfs: extract logic for getting VMA name constituents > > fs/procfs: implement efficient VMA querying API for /proc/<pid>/maps > > tools: sync uapi/linux/fs.h header into tools subdir > > selftests/bpf: make use of PROCFS_PROCMAP_QUERY ioctl, if available > > selftests/bpf: a simple benchmark tool for /proc/<pid>/maps APIs > > I'd love to see improvements like this for the Linux perf command. > Some thoughts: > > - Could we do something scalability wise better than a file > descriptor per pid? If a profiler is running in a container the cost > of many file descriptors can be significant, and something that > increases as machines get larger. Could we have a /proc/maps for all > processes? It's probably not a question to me, as it seems like an entirely different set of APIs. But it also seems a bit convoluted to mix together information about many address spaces. As for the cost of FDs, I haven't run into this limitation, and it seems like the trend in Linux in general is towards "everything is a file". Just look at pidfd, for example. Also, having a fd that can be queries has an extra nice property. For example, opening /proc/self/maps (i.e., process' own maps file) doesn't require any extra permissions, and then it can be transferred to another trusted process that would do address resolution/symbolization. In practice right now it's unavoidable to add extra caps/root permissions to the profiling process even if the only thing that it needs is contents of /proc/<pid>/maps (and the use case is as benign as symbol resolution). Not having an FD for this API would make this use case unworkable. > > - Something that is broken in perf currently is that we can race > between reading /proc and opening events on the pids it contains. For > example, perf top supports a uid option that first scans to find all > processes owned by a user then tries to open an event on each process. > This fails if the process terminates between the scan and the open > leading to a frequent: > ``` > $ sudo perf top -u `id -u` > The sys_perf_event_open() syscall returned with 3 (No such process) > for event (cycles:P). > ``` > It would be nice for the API to consider cgroups, uids and the like as > ways to get a subset of things to scan. This seems like putting too much into an API, tbh. It feels like mapping cgroupos/uids to their processes is its own way and if we don't have efficient APIs to do this, we should add it. But conflating it into "get VMAs from this process" seems wrong to me. > > - Some what related, the mmap perf events give data after the mmap > call has happened. As VMAs get merged this can lead to mmap perf > events looking like the memory overlaps (for jits using anonymous > memory) and we lack munmap/mremap events. Is this related to "VMA generation" that Arnaldo mentioned? I'd happily add it to the new API, as it's easily extensible, if the kernel already maintains it. If not, then it should be a separate work to discuss whether kernel *should* track this information. > > Jiri Olsa has looked at improvements in this area in the past. > > Thanks, > Ian > > > fs/proc/task_mmu.c | 290 +++++++++++--- > > include/uapi/linux/fs.h | 32 ++ > > .../perf/trace/beauty/include/uapi/linux/fs.h | 32 ++ > > tools/testing/selftests/bpf/.gitignore | 1 + > > tools/testing/selftests/bpf/Makefile | 2 +- > > tools/testing/selftests/bpf/procfs_query.c | 366 ++++++++++++++++++ > > tools/testing/selftests/bpf/test_progs.c | 3 + > > tools/testing/selftests/bpf/test_progs.h | 2 + > > tools/testing/selftests/bpf/trace_helpers.c | 105 ++++- > > 9 files changed, 763 insertions(+), 70 deletions(-) > > create mode 100644 tools/testing/selftests/bpf/procfs_query.c > > > > -- > > 2.43.0 > > > >
