From: Namhyung Kim <namhyung@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@redhat.com>, Ingo Molnar <mingo@kernel.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>,
Andi Kleen <ak@linux.intel.com>, Ian Rogers <irogers@google.com>,
Alexey Alexandrov <aalexand@google.com>
Subject: Re: [PATCH] perf/core: Emit PERF_RECORD_LOST for pinned events
Date: Tue, 19 Jan 2021 10:42:34 +0900 [thread overview]
Message-ID: <CAM9d7cg_Agin3C0iuigDzQjZEZNtVXPe9z9eaDZsdyNoVa_wxA@mail.gmail.com> (raw)
In-Reply-To: <YAWFkU+roDyMCgla@hirez.programming.kicks-ass.net>
On Mon, Jan 18, 2021 at 9:56 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Jan 18, 2021 at 08:44:20PM +0900, Namhyung Kim wrote:
> > Hi Peter,
> >
> > On Mon, Jan 18, 2021 at 7:11 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Mon, Jan 18, 2021 at 12:43:23PM +0900, Namhyung Kim wrote:
> > > > As of now we silently ignore pinned events when it's failed to be
> > > > scheduled and make it error state not try to schedule it again.
> > > > That means we won't get any samples for the event.
> > > >
> > > > But there's no way for users to notice and respond to it. Let's
> > > > emit a lost event with a new misc bit to indicate this situation.
> > >
> > > Users should get a read(2) error IIRC, does that not work?
> >
> > Ah, right. maybe I'm too specific to perf record's perspective.
> >
> > In perf record, it doesn't use read(2) so I thought it should
> > have the information in the stream of sample data.
>
> perf-record could of course do a read() at the end, to detect this.
OK, will add that.
>
> I don't think I object to having an even in the stream, but your LOST
> event is unfortunate in that it itself can get lost when there's no
> space in the buffer (which arguably is unlikely, but still).
>
> So from that point of view, I think overloading LOST is not so very nice
> for this.
But anything can get lost in case of no space.
Do you want to use something other than the LOST event?
Thanks,
Namhyung
next prev parent reply other threads:[~2021-01-19 1:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-18 3:43 [PATCH] perf/core: Emit PERF_RECORD_LOST for pinned events Namhyung Kim
2021-01-18 10:11 ` Peter Zijlstra
2021-01-18 11:44 ` Namhyung Kim
2021-01-18 12:56 ` Peter Zijlstra
2021-01-19 1:42 ` Namhyung Kim [this message]
2021-01-19 2:46 ` Andi Kleen
2021-01-19 3:11 ` Namhyung Kim
2021-01-20 11:53 ` Namhyung Kim
2021-01-20 12:16 ` Arnaldo Carvalho de Melo
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=CAM9d7cg_Agin3C0iuigDzQjZEZNtVXPe9z9eaDZsdyNoVa_wxA@mail.gmail.com \
--to=namhyung@kernel.org \
--cc=aalexand@google.com \
--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=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).