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:   Mon, 3 Aug 2020 18:26:36 +0200
From:   Jiri Olsa <jolsa@redhat.com>
To:     Ian Rogers <irogers@google.com>
Cc:     "Paul A. Clarke" <pc@us.ibm.com>, 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>
Subject: Re: [PATCHv4 00/19] perf metric: Add support to reuse metric
Message-ID: <20200803162636.GF139381@krava>
References: <20200729091908.1378911-1-jolsa@kernel.org>
 <20200801114050.GB377079@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>
 <CAP-5=fUjMH-VHaLhNjBhk4pSsAGs_9kUuy1N68RRF4d6E5e5Lg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAP-5=fUjMH-VHaLhNjBhk4pSsAGs_9kUuy1N68RRF4d6E5e5Lg@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 03, 2020 at 08:54:16AM -0700, Ian Rogers wrote:
> On Sat, Aug 1, 2020 at 4:41 AM Paul A. Clarke <pc@us.ibm.com> wrote:
> >
> > On Wed, Jul 29, 2020 at 11:18:49AM +0200, Jiri Olsa wrote:
> > > 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.
> > >
> > > v4 changes:
> > >   - removed acks from patch because it changed a bit
> > >     with the last fixes:
> > >       perf metric: Collect referenced metrics in struct metric_ref_node
> > >   - fixed runtime metrics [Kajol Jain]
> > >   - increased recursion depth [Paul A. Clarke]
> > >   - changed patches due to dependencies:
> > >       perf metric: Collect referenced metrics in struct metric_ref_node
> > >       perf metric: Add recursion check when processing nested metrics
> > >       perf metric: Rename struct egroup to metric
> > >       perf metric: Rename group_list to metric_list
> > >
> > > Also available in here:
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> > >   perf/metric
> >
> > I built and ran from the above git branch, and things seem to work.
> > Indeed, I was able to apply my changes to exploit the new capabilities
> > via modifications to tools/perf/pmu-events/arch/powerpc/power9/metrics.json,
> > as I posted earlier (and will submit once this set gets merged).
> >
> > Tested-by: Paul A. Clarke <pc@us.ibm.com>
> >
> > One thing I noted, but which also occurs without these patches, is that
> > the perf metrics are not computed unless run as root:
> > --
> > $ perf stat --metrics br_misprediction_percent command
> >
> >  Performance counter stats for 'command':
> >
> >      1,823,530,051      pm_br_pred:u
> >          2,662,705      pm_br_mpred_cmpl:u

it's because when you don't run as root, events will get the :u suffix,
so they will not match the events in metric.. we need to decide if we
want the metric to match events without modifiers or be strict about it

> >
> > $ /usr/bin/sudo perf stat --metrics br_misprediction_percent command
> >
> >  Performance counter stats for 'command':
> >
> >      1,824,655,269      pm_br_pred                #     0.09 br_misprediction_percent
> >          1,654,466      pm_br_mpred_cmpl
> > --
> >
> > Is that expected?  I don't think it's always been that way.
> 
> I agree Paul, this seems broken. I've noticed a bunch of issues with
> printing CSV, per-socket output and so on. Jiri may have a better idea
> but I plan to look at problems in this area later, and hopefully stick
> a few tests on it :-)

ok, that'd be great, thanks

jirka