Re: [PATCH RFC 00/10] counter read during perf sampling

From: Jiri Olsa
Date: Sun Sep 27 2015 - 15:57:13 EST

On Fri, Sep 25, 2015 at 02:57:14PM +0000, Liang, Kan wrote:


> > >
> > > Yes, the way to store the data from perf stat is better than pure
> > > script way. I guess your patch "perf stat record" can do that, right?
> > >
> > > If so, how should we run perf record and stat in parallel? By scripts
> > > or modify perf record/stat?
> > >
> > > Also, we need an option in perf report to merge the Right?
> >
> > either that or extra step with 'perf data merge' or somthing like that
> >
> Any update about "perf stat record" patch set? That will help a lot, if

I'll try to post new version this week

> we finally choose the 'perf data merge' way. Right?

I think we could do both ways.. let user choose whatever is more convenient


> >
> > the way I see it you implemented 'perf stat' logic within record command
> > you create counter (non sampling) and read it via read syscall
> >
> > I think it's good idea, but I think we should follow the way we do in perf
> > stat command and reuse the interface (and code)
> >
> > like having the 'stat' keyword separating the non-sampling config:
> >
> > $ perf record -e cycles stat -e 'uncore_imc_1/cas_count_read/' -I 10000 -
> > ./tchain_edit
> >
> Another thing is that there is limitation for --interval-print in perf stat.
> The interval must >= 100ms. However, we need the interval >=10ms.
> Any idea about where 100ms is from? Print limit?

I don't recall any reason for this limitation, IMO it was just convenient
to have higher unit because lower wasn't needed.. so I think we can change
it do 10ms


> >
> > 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 if you display only
single number at the end? overflow issues?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at