Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 25 Jul 2020 13:52:48 +0200
From:   Jiri Olsa <jolsa@redhat.com>
To:     "Paul A. Clarke" <pc@us.ibm.com>
Cc:     Jiri Olsa <jolsa@kernel.org>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Michael Petlan <mpetlan@redhat.com>,
        Andi Kleen <ak@linux.intel.com>,
        Kajol Jain <kjain@linux.ibm.com>,
        John Garry <john.garry@huawei.com>,
        Stephane Eranian <eranian@google.com>,
        Ian Rogers <irogers@google.com>
Subject: Re: [PATCHv3 00/19] perf metric: Add support to reuse metric
Message-ID: <20200725115248.GB1157288@krava>
References: <20200719181320.785305-1-jolsa@kernel.org>
 <20200721143702.GA15990@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>
 <20200722181158.GF981884@krava>
 <20200723155958.GA7141@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200723155958.GA7141@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jul 23, 2020 at 10:59:58AM -0500, Paul A. Clarke wrote:
> On Wed, Jul 22, 2020 at 08:11:58PM +0200, Jiri Olsa wrote:
> > On Tue, Jul 21, 2020 at 09:48:48AM -0500, Paul A. Clarke wrote:
> > > On Sun, Jul 19, 2020 at 08:13:01PM +0200, Jiri Olsa wrote:
> > > > hi,
> > > > this patchset is adding the support to reused metric in
> > > > another metric.
> > > > 
> > > > For example, to define IPC by using CPI with change like:
> > > > 
> > > >      {
> > > >          "BriefDescription": "Instructions Per Cycle (per Logical Processor)",
> > > > -        "MetricExpr": "INST_RETIRED.ANY / CPU_CLK_UNHALTED.THREAD",
> > > > +        "MetricExpr": "1/CPI",
> > > >          "MetricGroup": "TopDownL1",
> > > >          "MetricName": "IPC"
> > > >      },
> > > > 
> > > > I won't be able to find all the possible places we could
> > > > use this at, so I wonder you guys (who was asking for this)
> > > > would try it and come up with comments if there's something
> > > > missing or we could already use it at some places.
> > > > 
> > > > It's based on Arnaldo's tmp.perf/core.
> > > > 
> > > > v3 changes:
> > > >   - added some acks
> > > >   - some patches got merged
> > > >   - added missing zalloc include [John Garry]
> > > >   - added ids array outside the egroup object [Ian]
> > > >   - removed wrong m->has_constraint assignment [Ian]
> > > >   - renamed 'list' to 'metric_list' [Ian]
> > > >   - fixed group metric and added test for it [Paul A. Clarke]
> > > >   - fixed memory leak [Arnaldo]
> > > >   - using lowercase keys for metrics in hashmap, because jevents
> > > >     converts metric_expr to lowercase
> > > > 
> > > > Also available in here:
> > > >   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> > > >   perf/metric
> > > 
> > > These changes seem to be mostly working for me.
> > > 
> > > I attempted to exploit the new capability in the metrics definitions in
> > > tools/perf/pmu-events/arch/powerpc/power9/metrics.json.  Those changes
> > > are included below.
> > > 
> > > The one problem I found is with the "cpi_breakdown" metric group, as it
> > > no longer works:
> > > ```
> > > # perf stat --metrics cpi_breakdown ./command
> > > Cannot find metric or group `cpi_breakdown'
> > > ```
> > > 
> > > "cpi_breakdown" does show up in `perf list --metricgroup`, and all of the
> > > (95!) metrics listed in that group are usable, so it's not obvious whether
> > > my changes have a problem, or merely provoke one.
> > 
> > I underestimated the recursion depth setup for groups,
> > your change is working for me with following change:
> > 
> > -#define RECURSION_ID_MAX 100
> > +#define RECURSION_ID_MAX 1000
> 
> That indeed addressed the issue.
> 
> Is there a point where that limit was being hit and the code silently fails?

yes

> If so, should that failure be less silent?

I'll make it more verbose

thanks,
jirka