All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Petr Mladek <pmladek@suse.com>,
	Andrey Zhizhikin <andrey.z@gmail.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Kan Liang <kan.liang@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH v2 2/5] tools api fs: make xxx__mountpoint() more scalable
Date: Mon, 6 Apr 2020 11:07:21 -0300	[thread overview]
Message-ID: <20200406140721.GD29826@kernel.org> (raw)
In-Reply-To: <20200402154357.107873-3-irogers@google.com>

Em Thu, Apr 02, 2020 at 08:43:54AM -0700, Ian Rogers escreveu:
> 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.

Thanks, applied, lets see if someone screams...

- Arnaldo
 
> 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.
> 
> An alternative would be to just fix perf record. But it would solve
> the problem with hugetlbs__mountpoint() but there could be similar
> issues (possibly down the line) with other xxx_mountpoint() calls
> in perf or other tools.
> 
> Signed-off-by: Stephane Eranian <eranian@google.com>
> Reviewed-by: Ian Rogers <irogers@google.com>
> Acked-by: Jiri Olsa <jolsa@redhat.com>
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
>  tools/lib/api/fs/fs.c | 17 +++++++++++++++++
>  tools/lib/api/fs/fs.h | 12 ++++++++++++
>  2 files changed, 29 insertions(+)
> 
> diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c
> index 027b18f7ed8c..82f53d81a7a7 100644
> --- a/tools/lib/api/fs/fs.c
> +++ b/tools/lib/api/fs/fs.c
> @@ -90,6 +90,7 @@ struct fs {
>  	const char * const	*mounts;
>  	char			 path[PATH_MAX];
>  	bool			 found;
> +	bool			 checked;
>  	long			 magic;
>  };
>  
> @@ -111,31 +112,37 @@ static struct fs fs__entries[] = {
>  		.name	= "sysfs",
>  		.mounts	= sysfs__fs_known_mountpoints,
>  		.magic	= SYSFS_MAGIC,
> +		.checked = false,
>  	},
>  	[FS__PROCFS] = {
>  		.name	= "proc",
>  		.mounts	= procfs__known_mountpoints,
>  		.magic	= PROC_SUPER_MAGIC,
> +		.checked = false,
>  	},
>  	[FS__DEBUGFS] = {
>  		.name	= "debugfs",
>  		.mounts	= debugfs__known_mountpoints,
>  		.magic	= DEBUGFS_MAGIC,
> +		.checked = false,
>  	},
>  	[FS__TRACEFS] = {
>  		.name	= "tracefs",
>  		.mounts	= tracefs__known_mountpoints,
>  		.magic	= TRACEFS_MAGIC,
> +		.checked = false,
>  	},
>  	[FS__HUGETLBFS] = {
>  		.name	= "hugetlbfs",
>  		.mounts = hugetlbfs__known_mountpoints,
>  		.magic	= HUGETLBFS_MAGIC,
> +		.checked = false,
>  	},
>  	[FS__BPF_FS] = {
>  		.name	= "bpf",
>  		.mounts = bpf_fs__known_mountpoints,
>  		.magic	= BPF_FS_MAGIC,
> +		.checked = false,
>  	},
>  };
>  
> @@ -158,6 +165,7 @@ static bool fs__read_mounts(struct fs *fs)
>  	}
>  
>  	fclose(fp);
> +	fs->checked = true;
>  	return fs->found = found;
>  }
>  
> @@ -220,6 +228,7 @@ static bool fs__env_override(struct fs *fs)
>  		return false;
>  
>  	fs->found = true;
> +	fs->checked = true;
>  	strncpy(fs->path, override_path, sizeof(fs->path) - 1);
>  	fs->path[sizeof(fs->path) - 1] = '\0';
>  	return true;
> @@ -246,6 +255,14 @@ static const char *fs__mountpoint(int idx)
>  	if (fs->found)
>  		return (const char *)fs->path;
>  
> +	/* the mount point was already checked for the mount point
> +	 * but and did not exist, so return NULL to avoid scanning again.
> +	 * This makes the found and not found paths cost equivalent
> +	 * in case of multiple calls.
> +	 */
> +	if (fs->checked)
> +		return NULL;
> +
>  	return fs__get_mountpoint(fs);
>  }
>  
> diff --git a/tools/lib/api/fs/fs.h b/tools/lib/api/fs/fs.h
> index 936edb95e1f3..aa222ca30311 100644
> --- a/tools/lib/api/fs/fs.h
> +++ b/tools/lib/api/fs/fs.h
> @@ -18,6 +18,18 @@
>  	const char *name##__mount(void);	\
>  	bool name##__configured(void);		\
>  
> +/*
> + * The xxxx__mountpoint() entry points find the first match mount point for each
> + * filesystems listed below, where xxxx is the filesystem type.
> + *
> + * The interface is as follows:
> + *
> + * - If a mount point is found on first call, it is cached and used for all
> + *   subsequent calls.
> + *
> + * - If a mount point is not found, NULL is returned on first call and all
> + *   subsequent calls.
> + */
>  FS(sysfs)
>  FS(procfs)
>  FS(debugfs)
> -- 
> 2.26.0.rc2.310.g2932bb562d-goog
> 

-- 

- Arnaldo

  reply	other threads:[~2020-04-06 14:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02 15:43 [PATCH v2 0/5] Benchmark and improve event synthesis performance Ian Rogers
2020-04-02 15:43 ` [PATCH v2 1/5] perf bench: add event synthesis benchmark Ian Rogers
2020-04-06 14:07   ` Arnaldo Carvalho de Melo
2020-04-22 12:17   ` [tip: perf/core] perf bench: Add " tip-bot2 for Ian Rogers
2020-04-02 15:43 ` [PATCH v2 2/5] tools api fs: make xxx__mountpoint() more scalable Ian Rogers
2020-04-06 14:07   ` Arnaldo Carvalho de Melo [this message]
2020-04-22 12:17   ` [tip: perf/core] tools api fs: Make " tip-bot2 for Stephane Eranian
2020-04-02 15:43 ` [PATCH v2 3/5] perf synthetic-events: save 4kb from 2 stack frames Ian Rogers
2020-04-22 12:17   ` [tip: perf/core] " tip-bot2 for Ian Rogers
2020-04-02 15:43 ` [PATCH v2 4/5] tools api: add a lightweight buffered reading api Ian Rogers
2020-04-04  3:06   ` Namhyung Kim
2020-04-06 14:09     ` Arnaldo Carvalho de Melo
2020-04-06 16:15       ` Ian Rogers
2020-04-07 12:32         ` Arnaldo Carvalho de Melo
2020-04-10  3:43           ` Ian Rogers
2020-04-02 15:43 ` [PATCH v2 5/5] perf synthetic events: Remove use of sscanf from /proc reading Ian Rogers
2020-04-03 11:01 ` [PATCH v2 0/5] Benchmark and improve event synthesis performance Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200406140721.GD29826@kernel.org \
    --to=arnaldo.melo@gmail.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrey.z@gmail.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=tglx@linutronix.de \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.