On Fri, Sep 25, 2015 at 02:57:14PM +0000, Liang, Kan wrote: SNIP
> > > > > > 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 perf.data-s. 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 SNIP > > > > 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 SNIP > > > > 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? thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/