[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZeJJyCmXO9GxpDiF@tassilo>
Date: Fri, 1 Mar 2024 13:34:00 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Ian Rogers <irogers@...gle.com>
Cc: Perry Taylor <perry.taylor@...el.com>,
Samantha Alt <samantha.alt@...el.com>,
Caleb Biggers <caleb.biggers@...el.com>,
Weilin Wang <weilin.wang@...el.com>,
Edward Baker <edward.baker@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
John Garry <john.g.garry@...cle.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Jing Zhang <renyu.zj@...ux.alibaba.com>,
Thomas Richter <tmricht@...ux.ibm.com>,
James Clark <james.clark@....com>, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org,
Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH v1 02/20] perf jevents: Add idle metric for Intel models
>
> I see some of the gains as:
> - metrics that are human intelligible,
> - metrics for models that are no longer being updated,
> - removing copy-paste of metrics like tsx and smi across each model's
> metric json (less lines-of-code),
> - validation of events in a metric expression being in the event json
> for a model,
> - removal of forward porting metrics to a new model if the event
> names of the new model line up with those of previous,
> - in this patch kit there are metrics added that don't currently
> exist (more metrics should be better for users - yes there can always
> be bugs).
But then we have two ways to do things, and we already have a lot
of problems with regressions from complexity and a growing
bug backlog that nobody fixes.
Multiple ways to do basic operations seems just a recipe for
more and more fragmentation and similar problems.
The JSON format is certainly not perfect and has its share
of issues, but at least it's a standard now that is supported
by many vendors and creating new standards just because
you don't like some minor aspects doesn't seem like
a good approach. I'm sure the next person will come around
why wants Ruby metrics and the third would prefer to write
them in Rust. Who knows where it will stop.
Also in my experience this python stuff is unreliable because
half the people who build perf forget to install the python
libraries. Json at least works always.
Incrementional improvements are usually the way to do these
things.
-Andi
Powered by blists - more mailing lists