All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Stephane Eranian <eranian@google.com>,
	Ian Rogers <irogers@google.com>, Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 3/3] tools/lib/fs: Cache cgroupfs mount point
Date: Fri, 19 Feb 2021 08:37:00 -0300	[thread overview]
Message-ID: <YC+i3HDX2H4fB9ea@kernel.org> (raw)
In-Reply-To: <CAM9d7cj=XrpTDQuJ1vhax0drpO8rcbjQgUi3Gj8Q2476U7SmgQ@mail.gmail.com>

Em Fri, Feb 19, 2021 at 07:05:59PM +0900, Namhyung Kim escreveu:
> On Wed, Feb 17, 2021 at 9:58 PM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > Em Fri, Jan 08, 2021 at 02:51:44PM +0900, Namhyung Kim escreveu:
> > > On Wed, Jan 6, 2021 at 10:33 AM Namhyung Kim <namhyung@kernel.org> wrote:

> > > As you said, I think mostly we don't care as the accesses will happen
> > > in a short period of time.  But if you really care, maybe for the upcoming
> > > perf daemon changes, I think we can add an API to invalidate the cache
> > > or internal time-based invalidation logic (like remove it after 10 sec.).

> > Ok, we can have something in 'perf daemon' to periodically invalidate
> > this, maybe do a poor man inotify and when asking for the cgroup
> > mountpoint, check some characteristic of that file that changes when it
> > is modified, or plain use a timestamp and have some threshold.
 
> I thought about this again.
 
> We don't directly access the cgroups in the perf daemon.  It just
> creates new record processes so they'll see a new mountpoint whenever
> they started since this cache is shared within the process only.
 
> That means we don't need to care about the invalidate in the daemon
> but each perf record and perf stat should do it when they are required
> to do the work repeatedly.
 
> But looking at the code, the cgroup is set during event parsing (-G
> option) or early in the command (--for-each-cgroup option).  So cgroup
> info would not be changed even if the command runs repeatedly.
 
> So I think you can take the patch as is.

Its in perf/core branch on its way to Linus soon :-)

Thanks for checking it.

- Arnaldo

      reply	other threads:[~2021-02-19 11:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-16  9:05 [PATCH 1/3] tools/lib/fs: Prefer cgroup v1 path Namhyung Kim
2020-12-16  9:05 ` [PATCH 2/3] tools/lib/fs: Diet cgroupfs_find_mountpoint() Namhyung Kim
2020-12-28  8:31   ` Jiri Olsa
2020-12-29  5:27     ` Namhyung Kim
2020-12-29  9:39       ` Jiri Olsa
2020-12-16  9:05 ` [PATCH 3/3] tools/lib/fs: Cache cgroupfs mount point Namhyung Kim
2020-12-29 11:51   ` Arnaldo Carvalho de Melo
2021-01-06  1:33     ` Namhyung Kim
2021-01-08  5:51       ` Namhyung Kim
2021-01-21  4:33         ` Namhyung Kim
2021-02-17 12:58         ` Arnaldo Carvalho de Melo
2021-02-19 10:05           ` Namhyung Kim
2021-02-19 11:37             ` Arnaldo Carvalho de Melo [this message]

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=YC+i3HDX2H4fB9ea@kernel.org \
    --to=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /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.