From: Ben Gainey <Ben.Gainey@arm.com>
To: "mingo@kernel.org" <mingo@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>, nd <nd@arm.com>,
"acme@redhat.com" <acme@redhat.com>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
Will Deacon <Will.Deacon@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: BUG in "perf: Suppress AUX/OVERWRITE records"?
Date: Wed, 27 Mar 2019 10:23:06 +0000 [thread overview]
Message-ID: <1f645e7cacc20cc82249c7dd2db8361f1dd1726e.camel@arm.com> (raw)
In-Reply-To: <87wokk7k20.fsf@ashishki-desk.ger.corp.intel.com>
On Wed, 2019-03-27 at 11:17 +0200, Alexander Shishkin wrote:
> Ben Gainey <Ben.Gainey@arm.com> writes:
>
> > > It was an unintentional side effect that it also
> > > happened to coincide with context switches in the overwrite mode.
> >
> > I'm not using overwrite mode, I'm opening the mmap with PROT_WRITE
> > (i.e. in truncate mode).
>
> Now I get it. Does the below fix the problem for you?
Yes I guess I should have mentioned that in the first place.
Tested, working now as expected; I see regular PERF_RECORD_AUX, that
coincide with the context switch.
Thanks!
Ben
>
> From bf52320cce0e74a2c0d987db7bd571f7687b4f4f Mon Sep 17 00:00:00
> 2001
> From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Date: Wed, 27 Mar 2019 11:05:53 +0200
> Subject: [PATCH] perf: Fix AUX record suppression
>
> Commit 1627314fb54a33e ("perf: Suppress AUX/OVERWRITE records") has
> an
> unintended side-effect of also suppressing all AUX records with no
> flags
> and non-zero size, so all the regular records in the full trace mode.
> This breaks some use cases for people.
>
> Fix this by restoring "regular" AUX records to their former glory.
>
> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com
> >
> Fixes: 1627314fb54a33e ("perf: Suppress AUX/OVERWRITE records")
> Reported-by: Ben Gainey <Ben.Gainey@arm.com>
> CC: stable@vger.kernel.org # v4.20+
> ---
> kernel/events/ring_buffer.c | 33 +++++++++++++++------------------
> 1 file changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/kernel/events/ring_buffer.c
> b/kernel/events/ring_buffer.c
> index 678ccec60d8f..626256dc26c1 100644
> --- a/kernel/events/ring_buffer.c
> +++ b/kernel/events/ring_buffer.c
> @@ -455,24 +455,21 @@ void perf_aux_output_end(struct
> perf_output_handle *handle, unsigned long size)
> rb->aux_head += size;
> }
>
> -if (size || handle->aux_flags) {
> -/*
> - * Only send RECORD_AUX if we have something useful to
> communicate
> - *
> - * Note: the OVERWRITE records by themselves are not
> considered
> - * useful, as they don't communicate any *new*
> information,
> - * aside from the short-lived offset, that becomes
> history at
> - * the next event sched-in and therefore isn't useful.
> - * The userspace that needs to copy out AUX data in
> overwrite
> - * mode should know to use user_page::aux_head for the
> actual
> - * offset. So, from now on we don't output AUX records
> that
> - * have *only* OVERWRITE flag set.
> - */
> -
> -if (handle->aux_flags & ~(u64)PERF_AUX_FLAG_OVERWRITE)
> -perf_event_aux_event(handle->event, aux_head,
> size,
> - handle->aux_flags);
> -}
> +/*
> + * Only send RECORD_AUX if we have something useful to
> communicate
> + *
> + * Note: the OVERWRITE records by themselves are not considered
> + * useful, as they don't communicate any *new* information,
> + * aside from the short-lived offset, that becomes history at
> + * the next event sched-in and therefore isn't useful.
> + * The userspace that needs to copy out AUX data in overwrite
> + * mode should know to use user_page::aux_head for the actual
> + * offset. So, from now on we don't output AUX records that
> + * have *only* OVERWRITE flag set.
> + */
> +if (size || (handle->aux_flags &
> ~(u64)PERF_AUX_FLAG_OVERWRITE))
> +perf_event_aux_event(handle->event, aux_head, size,
> + handle->aux_flags);
>
> rb->user_page->aux_head = rb->aux_head;
> if (rb_need_aux_wakeup(rb))
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next prev parent reply other threads:[~2019-03-27 10:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 13:20 Ben Gainey
2019-03-26 7:02 ` Alexander Shishkin
2019-03-26 9:07 ` Ben Gainey
2019-03-27 9:17 ` Alexander Shishkin
2019-03-27 10:23 ` Ben Gainey [this message]
2019-04-02 10:47 ` Will Deacon
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=1f645e7cacc20cc82249c7dd2db8361f1dd1726e.camel@arm.com \
--to=ben.gainey@arm.com \
--cc=Will.Deacon@arm.com \
--cc=acme@redhat.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=nd@arm.com \
--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
all inboxes | Powered by JetHome®