From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ian Rogers <irogers@google.com>,
Mark Rutland <mark.rutland@arm.com>,
Marc Zyngier <maz@kernel.org>, Hector Martin <marcan@marcan.st>
Cc: Namhyung Kim <namhyung@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
James Clark <james.clark@arm.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH v1] perf parse-events: Make legacy events lower priority than sysfs/json
Date: Thu, 23 Nov 2023 18:49:49 -0300 [thread overview]
Message-ID: <ZV/I/Trfz7StsLsf@kernel.org> (raw)
In-Reply-To: <CAP-5=fV3_UamHcGusUVyo23OW6tRnmSc_tohuDf1KTf4F_os1g@mail.gmail.com>
Em Thu, Nov 23, 2023 at 07:18:57AM -0800, Ian Rogers escreveu:
> On Thu, Nov 23, 2023 at 6:37 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > On Wed, Nov 22, 2023 at 08:29:22PM -0800, Ian Rogers wrote:
> > > This is a large behavioral change:
> > > 1) the scope of the change means it should bake on linux-next and I
> > > don't believe should be a 6.7-rc fix.
> > I'm happy for this to bake, but I do think it needs to be backported for the
> > sake of users, especially given that it *restores* the old behaviour.
> It is going to change the behavior for a far larger set of users. I'm
> also concerned that:
> ```
> $ perf list
> ...
> cpu-cycles OR cpu/cpu-cycles/ [Kernel PMU event]
> ...
> ```
> implies that cpu/cpu-cycles/ is a synonym for cpu-cycles, which is no
> longer true (or pick another event from sysfs whose name is the same
> as a legacy event). I'm not sure what a fix in perf list for this
> would look like.
It is a mess, indeed, cpu-cycles should be equivalent to
cpu/cpu-cycles/, map to the same HW PMU counter.
But by now I think we need to just reword the output of perf list to not
equate those events, and instead provide a more informative output, if
that is at all possible.
Something like:
Legacy events:
cpu-cycles: some nice explanation about the intent for this one (Ingo's
probably).
And then:
PMU events: (and this is even less clear :-()
cpu/cpu-cycles/: other nice explanation about the intent for this one,
if different, on this arch, for the "legacy" cpu-cycles one.
The original intent, that I called "Ingo's" was to try to somehow
generalize some concepts (CPU cycles, for instante) so that we could get
a rough idea that would allow us to somehow compare results using the
tools over different architectures (and micro-arches, etc).
I think that with these generic names we're now in damage control mode:
what matters is to keep what people got used to to continue to hold. And
that is what I think is the main argument here.
And I really think we should just head people like Hector (perf power
users) and provide a way to aggregate "cycles" over all cores, probably
not in the default output, but in a really simple way, as he seems to
want that and I would'n t be surprised that that may be something useful
after all 8-).
So back to checking why this patch isn't working in some of the
container arches I test this whole shebang, sigh.
- Arnaldo
next prev parent reply other threads:[~2023-11-23 21:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-23 4:29 [RFC PATCH v1] perf parse-events: Make legacy events lower priority than sysfs/json Ian Rogers
2023-11-23 8:45 ` Hector Martin
2023-11-23 14:18 ` Arnaldo Carvalho de Melo
2023-11-23 21:15 ` Arnaldo Carvalho de Melo
2023-11-24 13:49 ` Arnaldo Carvalho de Melo
2023-11-23 14:37 ` Mark Rutland
2023-11-23 15:18 ` Ian Rogers
2023-11-23 21:49 ` Arnaldo Carvalho de Melo [this message]
2023-11-23 21:32 ` Arnaldo Carvalho de Melo
2023-11-24 11:19 ` Mark Rutland
2023-11-23 15:16 ` Marc Zyngier
2023-11-23 15:27 ` Ian Rogers
2023-11-23 16:09 ` Marc Zyngier
2023-11-23 17:59 ` Ian Rogers
2023-11-24 13:51 ` 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=ZV/I/Trfz7StsLsf@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.