From: Leo Yan <leo.yan@linaro.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
John Garry <john.garry@huawei.com>, Will Deacon <will@kernel.org>,
James Clark <james.clark@arm.com>,
German Gomez <german.gomez@arm.com>,
Ali Saidi <alisaidi@amazon.com>, Joe Mario <jmario@redhat.com>,
Adam Li <adam.li@amperecomputing.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 00/17] perf c2c: Support data source and display for Arm64
Date: Fri, 12 Aug 2022 23:20:10 +0800 [thread overview]
Message-ID: <20220812152010.GA74978@leoy-huanghe> (raw)
In-Reply-To: <YvZK20NEoIQATSH/@kernel.org>
On Fri, Aug 12, 2022 at 09:43:07AM -0300, Arnaldo Carvalho de Melo wrote:
[...]
> > One question: should I later continue to upstream the first patch for
> > syncing the kernel header perf_event.h after Peter.Z comes back?
>
> yes, and we may have to backtrack and find some other way to implement
> this if he is opposed, as he in the past didn't like
> perf_event_attr.type namespace being used by userspace only records such
> as PERF_RECORD_FINISHED_ROUND, PERF_RECORD_COMPRESSED, etc.
>
> In this case its different, I think its ok as we already have
> PERF_MEM_SNOOPX_FWD and PERF_MEM_SNOOPX_PEER probably will be emitted by
> the some of the architectures, from the kernel, right?
Yes, as I know x86 generates memory samples from kernel, and SNOOPX_PEER
can be a useful snooping flag for other archs.
As a last resort if SNOOPX_PEER is rejected, we can rollback to use
existed flag (like reusing PERF_MEM_SNOOPX_FWD), though this would be
ambiguous for expressing the memory operations on Arm64.
Thanks,
Leo
WARNING: multiple messages have this Message-ID (diff)
From: Leo Yan <leo.yan@linaro.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
John Garry <john.garry@huawei.com>, Will Deacon <will@kernel.org>,
James Clark <james.clark@arm.com>,
German Gomez <german.gomez@arm.com>,
Ali Saidi <alisaidi@amazon.com>, Joe Mario <jmario@redhat.com>,
Adam Li <adam.li@amperecomputing.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 00/17] perf c2c: Support data source and display for Arm64
Date: Fri, 12 Aug 2022 23:20:10 +0800 [thread overview]
Message-ID: <20220812152010.GA74978@leoy-huanghe> (raw)
In-Reply-To: <YvZK20NEoIQATSH/@kernel.org>
On Fri, Aug 12, 2022 at 09:43:07AM -0300, Arnaldo Carvalho de Melo wrote:
[...]
> > One question: should I later continue to upstream the first patch for
> > syncing the kernel header perf_event.h after Peter.Z comes back?
>
> yes, and we may have to backtrack and find some other way to implement
> this if he is opposed, as he in the past didn't like
> perf_event_attr.type namespace being used by userspace only records such
> as PERF_RECORD_FINISHED_ROUND, PERF_RECORD_COMPRESSED, etc.
>
> In this case its different, I think its ok as we already have
> PERF_MEM_SNOOPX_FWD and PERF_MEM_SNOOPX_PEER probably will be emitted by
> the some of the architectures, from the kernel, right?
Yes, as I know x86 generates memory samples from kernel, and SNOOPX_PEER
can be a useful snooping flag for other archs.
As a last resort if SNOOPX_PEER is rejected, we can rollback to use
existed flag (like reusing PERF_MEM_SNOOPX_FWD), though this would be
ambiguous for expressing the memory operations on Arm64.
Thanks,
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-08-12 15:20 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-04 4:28 [PATCH v5 00/17] perf c2c: Support data source and display for Arm64 Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 01/17] perf: Add SNOOP_PEER flag to perf mem data struct Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-07-20 18:45 ` Arnaldo Carvalho de Melo
2022-07-20 18:45 ` Arnaldo Carvalho de Melo
2022-07-20 18:46 ` Arnaldo Carvalho de Melo
2022-07-20 18:46 ` Arnaldo Carvalho de Melo
2022-07-21 0:27 ` Leo Yan
2022-07-21 0:27 ` Leo Yan
2022-08-08 16:40 ` ping " Arnaldo Carvalho de Melo
2022-06-04 4:28 ` [PATCH v5 02/17] perf tools: sync addition of PERF_MEM_SNOOPX_PEER Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 03/17] perf mem: Print snoop peer flag Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 04/17] perf arm-spe: Don't set data source if it's not a memory operation Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 05/17] perf arm-spe: Use SPE data source for neoverse cores Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 06/17] perf mem: Add statistics for peer snooping Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 07/17] perf c2c: Output " Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 08/17] perf c2c: Add dimensions for peer load operations Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 09/17] perf c2c: Add dimensions of peer metrics for cache line view Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 10/17] perf c2c: Add mean dimensions for peer operations Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 11/17] perf c2c: Use explicit names for display macros Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 12/17] perf c2c: Rename dimension from 'percent_hitm' to 'percent_costly_snoop' Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 13/17] perf c2c: Refactor node header Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 14/17] perf c2c: Refactor display string Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 15/17] perf c2c: Sort on peer snooping for load operations Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 16/17] perf c2c: Use 'peer' as default display for Arm64 Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-06-04 4:28 ` [PATCH v5 17/17] perf c2c: Update documentation for new display option 'peer' Leo Yan
2022-06-04 4:28 ` Leo Yan
2022-08-10 13:37 ` [PATCH v5 00/17] perf c2c: Support data source and display for Arm64 Arnaldo Carvalho de Melo
2022-08-10 13:37 ` Arnaldo Carvalho de Melo
2022-08-11 6:41 ` Leo Yan
2022-08-11 6:41 ` Leo Yan
2022-08-12 12:43 ` Arnaldo Carvalho de Melo
2022-08-12 12:43 ` Arnaldo Carvalho de Melo
2022-08-12 15:20 ` Leo Yan [this message]
2022-08-12 15:20 ` Leo Yan
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=20220812152010.GA74978@leoy-huanghe \
--to=leo.yan@linaro.org \
--cc=acme@kernel.org \
--cc=adam.li@amperecomputing.com \
--cc=alisaidi@amazon.com \
--cc=german.gomez@arm.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jmario@redhat.com \
--cc=john.garry@huawei.com \
--cc=jolsa@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.