[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F07701949A09@SHSMSX103.ccr.corp.intel.com>
Date: Mon, 28 Sep 2015 15:11:20 +0000
From: "Liang, Kan" <kan.liang@...el.com>
To: Jiri Olsa <jolsa@...hat.com>
CC: "acme@...nel.org" <acme@...nel.org>,
"jolsa@...nel.org" <jolsa@...nel.org>,
"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
"mingo@...hat.com" <mingo@...hat.com>,
"namhyung@...nel.org" <namhyung@...nel.org>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH RFC 00/10] counter read during perf sampling
> > >
> > > hum, how the --counter-read-interval data displayed then? it's not
> > > single number right?
> > >
> > No matter which way we choose, I think the output should be similar.
> >
> > As my original design, perf only output every --counter-read-interval
> > data in perf report -D.
> > For tui and stdio, it only output the aggregate number. So, yes, single
> number.
> >
> > I think it should be enough. In tui/stdio, perf gives user a roughly
> > image by the total number during the whole sampling process. If they
> > want details, they can check by report -D.
> > Considering the interval is only 10ms, if perf output everything in
> > tui/stdio, the output is too huge.
>
> what is the reason to read the counter multiple times
For doing sophisticated memory bandwidth analysis, it requires 10-20ms
interval to read uncore counter.
> if you display only
> single number at the end? overflow issues?
>
Display issue. If we set 10ms interval and do perf record stat for 10s, there
will be 1000 records per cpu. For a system with 64 cpu, there will be 64,000
number. We cannot show all of them in tui/stdio mode.
I think it's better to only show the total number in tui/stdio mode.
If the user want to do sophisticated analysis, they can use -D to dump all
records.
Thanks,
Kan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists