[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077536C3CBC@SHSMSX103.ccr.corp.intel.com>
Date: Fri, 24 Mar 2017 14:14:03 +0000
From: "Liang, Kan" <kan.liang@...el.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Andi Kleen <ak@...ux.intel.com>
CC: "peterz@...radead.org" <peterz@...radead.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"acme@...nel.org" <acme@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"eranian@...gle.com" <eranian@...gle.com>,
"jolsa@...nel.org" <jolsa@...nel.org>
Subject: RE: [PATCH 0/3]measure SMI cost
>
> > > > A new --smi-cost mode in perf stat is implemented to measure the
> > > > SMI cost by calculating cycles and aperf results. In practice, the
> > > > percentages of SMI cycles should be more useful than absolute value.
> > >
> > > That's only true for performance oriented analysis, but for
> > > analyzing the root cause of latencies the actual cycles are definitely
> interesting.
> >
> > perf stat also prints the absolute cycles of course (unless you do
> > --metric-only)
>
> So much for the theory. From the patch:
>
> + if (!force_metric_only)
> + metric_only = true;
>
The metric_only will be set by default in the patch. If user wants to get
the actual cycles, they can apply --no-metric-only.
Do you want me to make it clear in the changelog? Or you just don't like
that "metric_only=true" is set by default?
Thanks,
Kan
Powered by blists - more mailing lists