From: James Clark <James.Clark@arm.com>
To: Tan Xiaojun <tanxiaojun@huawei.com>,
Jeremy Linton <Jeremy.Linton@arm.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"acme@kernel.org" <acme@kernel.org>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"jolsa@redhat.com" <jolsa@redhat.com>,
"namhyung@kernel.org" <namhyung@kernel.org>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
"yao.jin@linux.intel.com" <yao.jin@linux.intel.com>,
"tmricht@linux.ibm.com" <tmricht@linux.ibm.com>,
"brueckner@linux.ibm.com" <brueckner@linux.ibm.com>,
"songliubraving@fb.com" <songliubraving@fb.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Kim Phillips <Kim.Phillips@amd.com>
Cc: "gengdongjiu@huawei.com" <gengdongjiu@huawei.com>,
"wxf.wang@hisilicon.com" <wxf.wang@hisilicon.com>,
"liwei391@huawei.com" <liwei391@huawei.com>,
"huawei.libin@huawei.com" <huawei.libin@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>, Al Grant <Al.Grant@arm.com>,
nd <nd@arm.com>
Subject: Re: [RFC PATCH 2/3] perf tools: Add support for "report" for some spe events
Date: Wed, 9 Oct 2019 09:48:55 +0000 [thread overview]
Message-ID: <b7e5ca2d-8c6c-8ab8-637e-a9aaebaf62a5@arm.com> (raw)
In-Reply-To: <637836d6-c884-1a55-7730-eeb45b590d39@huawei.com>
Hi Xiaojun,
> By the way, you mentioned before that you want the spe event to be in the form of "event:pp" like pebs. Is that the whole framework should be made similar to pebs? Or is it just a modification to the command format?
We're currently still investigating if it makes sense to modify the Perf event open syscall to use SPE when the "precise_ip" attribute is set. And then synthesize samples using the SPE data when available. This would keep the syscall interface more consistent between architectures.
And if tools other than Perf want more precise data, they don't have to be aware of SPE or any of the implementation defined details of it. For example the 'data source' encoding can be different from one micro architecture to the next. The kernel is probably the best place to handle this.
At the moment, every tool that wants to use the Perf syscall to get precise data on ARM would have to be aware of SPE and implement their own decoding.
> For the former, this may be a bit difficult. For the latter, there is currently no modification to the record part, so "-c -F, etc." is only for instructions rather than events, so it may be misunderstood by users.
>
> So I haven't figured out how to do. What do you think of this?
I think the patch at the moment is a good start to make SPE more accessible. And the changes I mentioned above wouldn't change the fact that the raw SPE data would still be available via the SPE PMU. So I think continuing with the patch as-is for now is the best idea.
James
next prev parent reply other threads:[~2019-10-09 9:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-02 9:40 [RFC PATCH 0/3] perf tools: Add support for "report" for some spe events Tan Xiaojun
2019-08-02 9:40 ` [RFC PATCH 1/3] perf tools: Move arm-spe-pkt-decoder.h/c to the new dir Tan Xiaojun
2019-08-02 9:40 ` [RFC PATCH 2/3] perf tools: Add support for "report" for some spe events Tan Xiaojun
2019-08-08 21:00 ` Jeremy Linton
2019-08-09 6:12 ` Tan Xiaojun
2019-10-04 13:46 ` James Clark
2019-10-08 5:59 ` Tan Xiaojun
2019-10-09 9:48 ` James Clark [this message]
2019-10-09 11:09 ` Tan Xiaojun
2019-10-09 11:49 ` Tan Xiaojun
2019-10-16 10:12 ` James Clark
2019-10-17 1:51 ` Tan Xiaojun
2019-10-17 6:08 ` Tan Xiaojun
2019-10-09 2:43 ` Tan Xiaojun
2019-10-09 3:06 ` Tan Xiaojun
2019-08-02 9:40 ` [RFC PATCH 3/3] perf report: add --spe options for arm-spe Tan Xiaojun
2019-08-21 12:38 ` James Clark
2019-08-22 1:44 ` Tan Xiaojun
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=b7e5ca2d-8c6c-8ab8-637e-a9aaebaf62a5@arm.com \
--to=james.clark@arm.com \
--cc=Al.Grant@arm.com \
--cc=Jeremy.Linton@arm.com \
--cc=Kim.Phillips@amd.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=brueckner@linux.ibm.com \
--cc=gengdongjiu@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=huawei.libin@huawei.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=liwei391@huawei.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=nd@arm.com \
--cc=peterz@infradead.org \
--cc=songliubraving@fb.com \
--cc=tanxiaojun@huawei.com \
--cc=tmricht@linux.ibm.com \
--cc=wxf.wang@hisilicon.com \
--cc=yao.jin@linux.intel.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 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).