From: Peter Zijlstra <peterz@infradead.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@redhat.com>, Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Stephane Eranian <eranian@google.com>,
Andi Kleen <ak@linux.intel.com>, Ian Rogers <irogers@google.com>,
Song Liu <songliubraving@fb.com>
Subject: Re: [PATCH v3] perf/core: Set event shadow time for inactive events too
Date: Fri, 10 Dec 2021 11:33:41 +0100 [thread overview]
Message-ID: <20211210103341.GS16608@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CAM9d7ciJTJB1rumzmxGeJrAdeE9R4eXhtJRUQGj9y6DBN-ovig@mail.gmail.com>
On Thu, Dec 09, 2021 at 01:35:11PM -0800, Namhyung Kim wrote:
> On Thu, Dec 9, 2021 at 3:26 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Sun, Dec 05, 2021 at 02:48:43PM -0800, Namhyung Kim wrote:
> >
> > > Actually 18446744069443110306 is 0xffffffff01b345a2 so it seems to
> > > have a negative enabled time. In fact, bperf keeps values returned by
> > > bpf_perf_event_read_value() which calls perf_event_read_local(), and
> > > accumulates delta between two calls. When event->shadow_ctx_time is
> > > not set, it'd return invalid enabled time which is bigger than normal.
> >
> > *that*, how does it happen that shadow_time isn't set? It should be last
> > set when the event switches to INACTIVE, no?
>
> As you can see, perf_event_set_state() doesn't set the shadow time.
> It's called from event_sched_in() which might result in ACTIVE or
> INACTIVE. But the problem is that there's a case that event_sched_in
> was not called at all - when group_can_go_on() returns false.
>
> > At which point the logic in
> > perf_event_read_local() should make @enabled move forward while @running
> > stays put.
>
> It's not about updating event->total_time_enabled, it only
> afftects the returned value of @enabled.
>
> I'd say the time calculation is broken so it'd break @running
> as well. But this case can only happen on INACTIVE -
> otherwise it'd call event_sched_in() and update the shadow
> time properly, so no issue there. And then we can see
> the broken value of enabled time only.
I'm thinking this is a cgroup specific thing. Normally the shadow_time
thing is simply a relative displacement between event-time and the
global clock. That displacement never changes, except when you do
IOC_DISABLE/IOC_ENABLE.
However, for cgroup things are different, since the cgroup events aren't
unconditionally runnable, that is, the enabled time should only count
when the cgroup is active, right?
So perhaps perf_event_read_local() should use a cgroup clock instead of
perf_clock() for cgroup events.
Let me think about that some more...
next prev parent reply other threads:[~2021-12-10 10:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-05 22:48 [PATCH v3] perf/core: Set event shadow time for inactive events too Namhyung Kim
2021-12-06 23:11 ` Song Liu
2021-12-08 23:22 ` Peter Zijlstra
2021-12-09 5:52 ` Namhyung Kim
2021-12-09 8:21 ` Peter Zijlstra
2021-12-09 11:26 ` Peter Zijlstra
2021-12-09 11:34 ` Peter Zijlstra
2021-12-09 21:51 ` Namhyung Kim
2021-12-10 10:19 ` Peter Zijlstra
2021-12-10 18:59 ` Namhyung Kim
2021-12-20 9:39 ` Peter Zijlstra
2021-12-09 21:35 ` Namhyung Kim
2021-12-10 10:33 ` Peter Zijlstra [this message]
2021-12-10 23:19 ` Namhyung Kim
2021-12-17 16:35 ` Peter Zijlstra
2021-12-18 9:09 ` Song Liu
2021-12-20 9:30 ` Peter Zijlstra
2021-12-20 9:54 ` Peter Zijlstra
2021-12-21 12:39 ` Peter Zijlstra
2021-12-20 12:19 ` Peter Zijlstra
2021-12-21 5:54 ` Namhyung Kim
2021-12-21 7:23 ` Song Liu
2021-12-21 11:21 ` Peter Zijlstra
2022-01-18 11:17 ` [tip: perf/urgent] perf: Fix perf_event_read_local() time tip-bot2 for Peter Zijlstra
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=20211210103341.GS16608@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=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=songliubraving@fb.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.