From: Stephane Eranian <eranian@google.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@linux.intel.com>, Ian Rogers <irogers@google.com>,
Gabriel Marin <gmx@google.com>
Subject: Re: [RFC] perf/core: Add an ioctl to get a number of lost samples
Date: Wed, 11 Aug 2021 16:57:25 -0700 [thread overview]
Message-ID: <CABPqkBT3qqDC7cU+XwNcpST66+X6PMmsfwo96_0fTGVKn19ycw@mail.gmail.com> (raw)
In-Reply-To: <CAM9d7cjJKFZUQkYW2U6eBmdQJdSOrVDe0FiojhNBbknsKoEyTQ@mail.gmail.com>
On Wed, Aug 11, 2021 at 1:57 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Wed, Aug 11, 2021 at 12:57 PM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Wed, Aug 11, 2021 at 12:33:38PM -0700, Stephane Eranian wrote:
> > > On Wed, Aug 11, 2021 at 8:04 AM Jiri Olsa <jolsa@redhat.com> wrote:
> > > >
> > > > On Tue, Aug 10, 2021 at 11:21:35PM -0700, Namhyung Kim wrote:
> > > > > Sometimes we want to know an accurate number of samples even if it's
> > > > > lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
> > > > > might be shared with other events. So it's hard to know per-event
> > > > > lost count.
> > > > >
> > > > > Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
> > > > > retrieve it from userspace.
> > > > >
> > > > > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> > > > > ---
> > > > > include/linux/perf_event.h | 2 ++
> > > > > include/uapi/linux/perf_event.h | 1 +
> > > > > kernel/events/core.c | 9 +++++++++
> > > > > kernel/events/ring_buffer.c | 5 ++++-
> > > > > 4 files changed, 16 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > > > index f5a6a2f069ed..44d72079c77a 100644
> > > > > --- a/include/linux/perf_event.h
> > > > > +++ b/include/linux/perf_event.h
> > > > > @@ -756,6 +756,8 @@ struct perf_event {
> > > > > struct pid_namespace *ns;
> > > > > u64 id;
> > > > >
> > > > > + atomic_t lost_samples;
> > > > > +
> > > > > u64 (*clock)(void);
> > > > > perf_overflow_handler_t overflow_handler;
> > > > > void *overflow_handler_context;
> > > > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > > > > index bf8143505c49..24397799127d 100644
> > > > > --- a/include/uapi/linux/perf_event.h
> > > > > +++ b/include/uapi/linux/perf_event.h
> > > > > @@ -505,6 +505,7 @@ struct perf_event_query_bpf {
> > > > > #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> > > > > #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
> > > > > #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
> > > > > +#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
> > > >
> > > > would it be better to use the read syscall for that?
> > > > https://lore.kernel.org/lkml/20210622153918.688500-5-jolsa@kernel.org/
> > > >
> > > > that patchset ended up on me not having a way to reproduce the
> > > > issue you guys wanted the fix for ;-) the lost count is there
> > > > as well
> > > >
> > > Does the read format approach succeed even when the event is in error state?
> >
> > nope..
> >
> > /*
> > * Return end-of-file for a read on an event that is in
> > * error state (i.e. because it was pinned but it couldn't be
> > * scheduled on to the CPU at some point).
> > */
> > if (event->state == PERF_EVENT_STATE_ERROR)
> > return 0;
> >
>
> By the way, it'd be nice if the kernel would provide a way for
> better error reporting. There are many cases return -EINVAL
> and it's hard to know what's the problem exactly.
>
+1. If the kernel has more precise error reporting, then the tool
could be more helpful in its error reporting and not try to guess with
heuristics.
next prev parent reply other threads:[~2021-08-11 23:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-11 6:21 [RFC] perf/core: Add an ioctl to get a number of lost samples Namhyung Kim
2021-08-11 13:12 ` Andi Kleen
2021-08-11 15:04 ` Jiri Olsa
2021-08-11 19:33 ` Stephane Eranian
2021-08-11 19:57 ` Jiri Olsa
2021-08-11 20:57 ` Namhyung Kim
2021-08-11 23:57 ` Stephane Eranian [this message]
2021-08-11 20:54 ` Namhyung Kim
2021-08-24 14:02 ` Peter Zijlstra
2021-08-24 17:55 ` Namhyung Kim
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=CABPqkBT3qqDC7cU+XwNcpST66+X6PMmsfwo96_0fTGVKn19ycw@mail.gmail.com \
--to=eranian@google.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=gmx@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).