On Fri, May 03, 2024 at 05:30:06PM -0700, Andrii Nakryiko wrote: > I also did an strace run of both cases. In text-based one the tool did > 68 read() syscalls, fetching up to 4KB of data in one go. Why not fetch more at once? And I have a fun 'readfile()' syscall implementation around here that needs justification to get merged (I try so every other year or so) that can do the open/read/close loop in one call, with the buffer size set by userspace if you really are saying this is a "hot path" that needs that kind of speedup. But in the end, io_uring usually is the proper api for that instead, why not use that here instead of slow open/read/close if you care about speed? > In comparison, > ioctl-based implementation had to do only 6 ioctl() calls to fetch all > relevant VMAs. > > It is projected that savings from processing big production applications > would only widen the gap in favor of binary-based querying ioctl API, as > bigger applications will tend to have even more non-executable VMA > mappings relative to executable ones. Define "bigger applications" please. Is this some "large database company workload" type of thing, or something else? thanks, greg k-h
