[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqJ8nhmx4U8efE2_FuVkacMYxHys4OZXv9PmdTXjZP1x4A@mail.gmail.com>
Date: Mon, 26 Sep 2022 08:32:21 -0500
From: Rob Herring <robh@...nel.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Jiri Olsa <jolsa@...nel.org>, Leo Yan <leo.yan@...aro.org>,
linux-perf-users <linux-perf-users@...r.kernel.org>,
James Clark <james.clark@....com>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] perf: Skip and warn on unknown format 'configN' attrs
On Fri, Sep 16, 2022 at 1:12 PM Namhyung Kim <namhyung@...nel.org> wrote:
>
> On Wed, Sep 14, 2022 at 1:09 PM Rob Herring <robh@...nel.org> wrote:
> >
> > If the kernel exposes a new perf_event_attr field in a format attr, perf
> > will return an error stating the specified PMU can't be found. For
> > example, a format attr with 'config3:0-63' causes an error as config3 is
> > unknown to perf. This causes a compatibility issue between a newer
> > kernel with older perf tool.
> >
> > Before this change with a kernel adding 'config3' I get:
> >
> > $ perf record -e arm_spe// -- true
> > event syntax error: 'arm_spe//'
> > \___ Cannot find PMU `arm_spe'. Missing kernel support?
> > Run 'perf list' for a list of valid events
> >
> > Usage: perf record [<options>] [<command>]
> > or: perf record [<options>] -- <command> [<options>]
> >
> > -e, --event <event> event selector. use 'perf list' to list
> > available events
> >
> > After this change, I get:
> >
> > $ perf record -e arm_spe// -- true
> > WARNING: 'arm_spe_0' format 'inv_event_filter' requires 'perf_event_attr::config3' which is not supported by this version of perf!
> > [ perf record: Woken up 2 times to write data ]
> > [ perf record: Captured and wrote 0.091 MB perf.data ]
> >
> > To support unknown configN formats, rework the YACC implementation to
> > pass any config[0-9]+ format to perf_pmu__new_format() to handle with a
> > warning.
>
> It only handles configN formats but it might add a completely different
> name later, right?
Right. An unknown configN is a warning. An unknown name is still an
error as before. Given that sysfs format attrs are for mapping fields
which could be anything to "generic" perf_event_attr fields, how would
we ever have anything other than configN?
Rob
Powered by blists - more mailing lists