From: Ian Rogers <irogers@google.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
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,
bpf@vger.kernel.org, Atish Patra <atishp@rivosinc.com>,
linux-riscv@lists.infradead.org,
Beeman Strong <beeman@rivosinc.com>
Subject: Re: [PATCH v1 0/9] Consistently prefer sysfs/json events
Date: Mon, 15 Apr 2024 09:59:00 -0700 [thread overview]
Message-ID: <CAP-5=fWhPTWiRjiUW7vRCetm26fYgOWfHzV4Qig3rSfe-x5VLQ@mail.gmail.com> (raw)
In-Reply-To: <20240415063626.453987-1-irogers@google.com>
On Sun, Apr 14, 2024 at 11:36 PM Ian Rogers <irogers@google.com> wrote:
>
> As discussed in:
> https://lore.kernel.org/lkml/20240217005738.3744121-1-atishp@rivosinc.com/
> preferring sysfs/json events consistently (with or without a given
> PMU) will enable RISC-V's hope to customize legacy events in the perf
> tool.
>
> Some minor clean-up is performed on the way.
A side-effect of prioritizing sysfs/json events over legacy hardware
events is that the hard coded metric logic in stat-shadow fails:
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/stat-shadow.c?h=perf-tools-next#n100
This is because the hard coded metrics assume that legacy events will
be used. Rather than make the hard coded metrics match sysfs/json I
think it is better to remove the hard coded metrics. This is because
the hard coded metrics lack checks on things like grouping that rather
than fix should be transitioned to json metrics. My preference for the
json metrics is to generate them using the python generation scripts
that are out for review.
Thanks,
Ian
> Ian Rogers (9):
> perf parse-events: Factor out '<event_or_pmu>/.../' parsing
> perf parse-events: Directly pass PMU to parse_events_add_pmu
> perf parse-events: Avoid copying an empty list
> perf pmu: Refactor perf_pmu__match
> perf tests parse-events: Use branches rather than cache-references
> perf parse-events: Legacy cache names on all PMUs and lower priority
> perf parse-events: Handle PE_TERM_HW in name_or_raw
> perf parse-events: Constify parse_events_add_numeric
> perf parse-events: Prefer sysfs/json hardware events over legacy
>
> tools/perf/tests/parse-events.c | 6 +-
> tools/perf/util/parse-events.c | 201 ++++++++++++++++++++++----------
> tools/perf/util/parse-events.h | 16 +--
> tools/perf/util/parse-events.l | 76 ++++++------
> tools/perf/util/parse-events.y | 166 +++++++++-----------------
> tools/perf/util/pmu.c | 27 +++--
> tools/perf/util/pmu.h | 2 +-
> 7 files changed, 262 insertions(+), 232 deletions(-)
>
> --
> 2.44.0.683.g7961c838ac-goog
>
prev parent reply other threads:[~2024-04-15 16:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 6:36 [PATCH v1 0/9] Consistently prefer sysfs/json events Ian Rogers
2024-04-15 6:36 ` [PATCH v1 1/9] perf parse-events: Factor out '<event_or_pmu>/.../' parsing Ian Rogers
2024-04-15 6:36 ` [PATCH v1 2/9] perf parse-events: Directly pass PMU to parse_events_add_pmu Ian Rogers
2024-04-15 6:36 ` [PATCH v1 3/9] perf parse-events: Avoid copying an empty list Ian Rogers
2024-04-15 6:36 ` [PATCH v1 4/9] perf pmu: Refactor perf_pmu__match Ian Rogers
2024-04-15 6:36 ` [PATCH v1 5/9] perf tests parse-events: Use branches rather than cache-references Ian Rogers
2024-04-15 6:36 ` [PATCH v1 6/9] perf parse-events: Legacy cache names on all PMUs and lower priority Ian Rogers
2024-04-15 6:36 ` [PATCH v1 7/9] perf parse-events: Handle PE_TERM_HW in name_or_raw Ian Rogers
2024-04-15 6:36 ` [PATCH v1 8/9] perf parse-events: Constify parse_events_add_numeric Ian Rogers
2024-04-15 6:36 ` [PATCH v1 9/9] perf parse-events: Prefer sysfs/json hardware events over legacy Ian Rogers
2024-04-15 16:59 ` Ian Rogers [this message]
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='CAP-5=fWhPTWiRjiUW7vRCetm26fYgOWfHzV4Qig3rSfe-x5VLQ@mail.gmail.com' \
--to=irogers@google.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=atishp@rivosinc.com \
--cc=beeman@rivosinc.com \
--cc=bpf@vger.kernel.org \
--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=linux-riscv@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).