From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Ben Gainey <Ben.Gainey@arm.com>,
"mingo\@kernel.org" <mingo@kernel.org>,
"peterz\@infradead.org" <peterz@infradead.org>,
"acme\@redhat.com" <acme@redhat.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>,
alexander.shishkin@linux.intel.com
Subject: Re: BUG in "perf: Suppress AUX/OVERWRITE records"?
Date: Tue, 26 Mar 2019 09:02:40 +0200 [thread overview]
Message-ID: <87k1gm86en.fsf@ashishki-desk.ger.corp.intel.com> (raw)
In-Reply-To: <ca9bbbdfada4c02eacb5064fce5d187d0f13f4f0.camel@arm.com>
Ben Gainey <Ben.Gainey@arm.com> writes:
> Hi all
>
> Regarding commit 1627314fb54a33ebd23bd08f2e215eaed0f44712 "perf:
> Suppress AUX/OVERWRITE records", I have found that I no longer receive
> PERF_RECORD_AUX on context switch when collecting data from the arm_spe
> PMU driver. This is because, on context switch, the arm_spe driver
> calls perf_aux_output_end with `handle->aux_flags == 0`, failing the
> test added in this commit.
>
> This is a problem as it means when capturing data for multiple threads
> (using perf_event_open) where AUX data is written to a per-cpu buffer,
> I can no longer accurately attribute SPE AUX data to an individual
> thread.
Sounds like PERF_RECORD_SWITCH should be sufficient for your purposes,
have you considered that?
> If I read the intent of the commit as to remove OVERWRITE AUX records,
> then it seems the added if condition is incorrect and should probably
> be formulated as:
>
> if ((handle->aux_flags & ~(u64)PERF_AUX_FLAG_OVERWRITE) || !handle-
>>aux_flags)
>
> Is this correct (and would you like a patch?), or is my use of
> PERF_RECORD_AUX incorrect in this case?
No, the point of AUX records is to communicate useful things about the
data in AUX buffer. It was an unintentional side effect that it also
happened to coincide with context switches in the overwrite mode.
Thanks,
--
Alex
next prev parent reply other threads:[~2019-03-26 7:02 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 [this message]
2019-03-26 9:07 ` Ben Gainey
2019-03-27 9:17 ` Alexander Shishkin
2019-03-27 10:23 ` Ben Gainey
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=87k1gm86en.fsf@ashishki-desk.ger.corp.intel.com \
--to=alexander.shishkin@linux.intel.com \
--cc=Ben.Gainey@arm.com \
--cc=Will.Deacon@arm.com \
--cc=acme@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®