From: Leo Yan <leo.yan@linaro.org>
To: Rob Herring <robh@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
James Clark <james.clark@arm.com>,
linux-perf-users <linux-perf-users@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] perf: Skip and warn on unknown format 'configN' attrs
Date: Tue, 13 Sep 2022 10:17:08 +0800 [thread overview]
Message-ID: <Yx/oJDvan6ctGYtX@leoy-yangtze.lan> (raw)
In-Reply-To: <CAL_JsqJGrUrahj-T+k7T9GAF+T8=y03YUTG2V+v52styFFDW_Q@mail.gmail.com>
On Mon, Sep 12, 2022 at 08:55:32AM -0500, Rob Herring wrote:
[...]
> > If this is the case,
> > it's good to add a fixes tag like below?
> >
> > Fixes: cd82a32e9924 ("perf tools: Add perf pmu object to access pmu format definition")
>
> Probably not too important given this is from 2012.
Which means since 2012 there have no requirement for config3 :)
AFAICT, perf tool should be forward compatible, so I think it's good
for this patch to be landed on (old) LTS kernels.
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > ---
> > > v2:
> > > - Rework YACC code to handle configN formats in C code
> > > - Add a warning when an unknown configN attr is found
> > >
> > > v1: https://lore.kernel.org/all/20220901184709.2179309-1-robh@kernel.org/
> > > ---
> > > tools/perf/util/pmu.c | 6 ++++++
> > > tools/perf/util/pmu.l | 2 --
> > > tools/perf/util/pmu.y | 15 ++++-----------
> > > 3 files changed, 10 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> > > index 89655d53117a..6757db7d559c 100644
> > > --- a/tools/perf/util/pmu.c
> > > +++ b/tools/perf/util/pmu.c
> > > @@ -1475,6 +1475,12 @@ int perf_pmu__new_format(struct list_head *list, char *name,
> > > {
> > > struct perf_pmu_format *format;
> > >
> > > + if (config > PERF_PMU_FORMAT_VALUE_CONFIG2) {
> >
> > It's good to add a new macro PERF_PMU_FORMAT_VALUE_CONFIG_END in
> > util/pmu.h. Then at here we can check the condition:
>
> Sure.
>
> >
> > if (config >= PERF_PMU_FORMAT_VALUE_CONFIG_END) {
> >
> > > + pr_warning("WARNING: format '%s' requires 'config%d' which is not supported by this version of perf!\n",
> > > + name, config);
> >
> > ... so at here we can print log like:
> >
> > pr_warning("WARNING: format '%s' requires 'config%d' which is not "
> > "supported by this version of perf (maximum config%d)!\n",
> > name, config, PERF_PMU_FORMAT_VALUE_CONFIG_END - 1);
>
> I was trying to keep it to one line and given configN isn't expanded
> frequently it should be simple enough to figure out what version you
> need.
It's fine for me.
> > The rest of this patch is fine for me.
> >
> > As a side topic, I know you want to support the SPEv1.2 feature with
> > config3, seems to me a complete patch set series should include the
> > changes for supporting config3 as well. This can give more clear view
> > for how to fix incompatibility issue between old and new kernels, and
> > how to support config3 in the latest kernel, but it's fine for me if
> > you want to split into two patch sets.
>
> I've sent out the SPE kernel support separately. I was told by Arnaldo
> to split perf tool and kernel side changes.
To be clear, it's right to split kernel and userspace parts into two
patch set, but for userspace change I cannot find you sent patch
to support config3 in perf tool, something in the [1] is missed,
otherwise I don't think you provide complete support for config3 (and
thus we have no chance to use new event format).
Thanks,
Leo
[1] https://termbin.com/vdph
prev parent reply other threads:[~2022-09-13 2:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-09 20:45 [PATCH v2] perf: Skip and warn on unknown format 'configN' attrs Rob Herring
2022-09-12 10:35 ` Leo Yan
2022-09-12 13:55 ` Rob Herring
2022-09-13 2:17 ` Leo Yan [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=Yx/oJDvan6ctGYtX@leoy-yangtze.lan \
--to=leo.yan@linaro.org \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.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=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox