Messages in this thread | | | Date | Mon, 30 Mar 2020 15:25:51 +0200 | From | Jiri Olsa <> | Subject | Re: [PATCH] tools api fs: make xxx__mountpoint() more scalable |
| |
On Fri, Mar 27, 2020 at 06:42:21PM -0700, Ian Rogers wrote: > From: Stephane Eranian <eranian@google.com> > > The xxx_mountpoint() interface provided by fs.c finds > mount points for common pseudo filesystems. The first > time xxx_mountpoint() is invoked, it scans the mount > table (/proc/mounts) looking for a match. If found, it > is cached. The price to scan /proc/mounts is paid once > if the mount is found. > > When the mount point is not found, subsequent calls to > xxx_mountpoint() scan /proc/mounts over and over again. > There is no caching. > > This causes a scaling issue in perf record with hugeltbfs__mountpoint(). > The function is called for each process found in synthesize__mmap_events(). > If the machine has thousands of processes and if the /proc/mounts has many > entries this could cause major overhead in perf record. We have observed > multi-second slowdowns on some configurations. > > As an example on a laptop: > > Before: > $ sudo umount /dev/hugepages > $ strace -e trace=openat -o /tmp/tt perf record -a ls > $ fgrep mounts /tmp/tt > 285 > > After: > $ sudo umount /dev/hugepages > $ strace -e trace=openat -o /tmp/tt perf record -a ls > $ fgrep mounts /tmp/tt > 1 > > One could argue that the non-caching in case the moint point is not found > is intentional. That way subsequent calls may discover a moint point if > the sysadmin mounts the filesystem. But the same argument could be made > against caching the mount point. It could be unmounted causing errors. > It all depends on the intent of the interface. This patch assumes it > is expected to scan /proc/mounts once. The patch documents the caching > behavior in the fs.h header file.
I agree, I don't think we have a code that would intentionaly make use of the later discovery.. if that's ever needed we could add function that invalidates the cache
Acked-by: Jiri Olsa <jolsa@redhat.com>
thanks, jirka
| |