> On Tue, Sep 22, 2015 at 10:13:33AM -0400, kan.li...@intel.com wrote: > > From: Kan Liang <kan.li...@intel.com> > > > > The patch series intends to read counter statistics with fixed > > frequency during sampling. The instant benefit is that we can read > > memory bandwidth from uncore event during cpu PMU event is > sampling. > > > > Introduce 'C' event/group modifier. The event with this modifier will > > do counting not sampling. If a group with this modifier, only group > > leader do sampling. The counter statistics will be wrote in new RECORD > > type PERF_RECORD_COUNTER_READ and stored in perf.data. > > So perf report can present the counter statistics data accordingly. > > > > There may be an alternative way to get counter statistics during > > sampling by running perf record and perf stat together by script. > > But the script way have various issue and complex to parses the > > output. > > just a thought, but isn't the way then llow to store the data from perf > stat? ;-) and be able to merge perf.data-s from perf record and stat > afterwards
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? > > > > > Example: > > > > $perf record -e 'cycles,uncore_imc_1/cas_count_read/C' > > --counter-read-interval 10 -a ./tchain_edit [ perf record: Woken up > > 438 times to write data ] [ perf record: Captured and wrote 1.232 MB > > perf.data (17901 samples) ] > > but if we go this way I think we should keep/allow all the options perf stat Do you mean something like "perf record stat"? That's not the way I designed. I don't want to run perf record and perf stat together in one command. I just want to do similar thing like what sample read did. Sample read can read counters on each sample. While the counter read can read counters in a fix frequency (set by --counter-read-interval). So it's an extension of perf record. It applies all possible options of perf record, like -C -a -g... I introduce a new option --counter-read-interval is because that there is no interval options in perf record. > > something like: > $ perf record -e cycles stat -e 'uncore_imc_1/cas_count_read/' -I 10000 - > a ./tchain_edit > > with all the stat option we allow -c -F ... > and reusing existing stat code > > > $perf report -D > > > > 0x3cae0 [0x28]: PERF_RECORD_COUNTER_READ: > uncore_imc_1/cas_count_read/C > > CPU 0: val 1205 ena 2046148 run 2046148 > > > > 0x3cb08 [0x28]: PERF_RECORD_COUNTER_READ: > uncore_imc_1/cas_count_read/C > > CPU 18: val 1315 ena 2001918 run 2001918 > > > > 0x3dba0 [0x28]: PERF_RECORD_COUNTER_READ: > uncore_imc_1/cas_count_read/C > > CPU 0: val 1588 ena 12191520 run 12191520 > > > > 0x3dbc8 [0x28]: PERF_RECORD_COUNTER_READ: > uncore_imc_1/cas_count_read/C > > CPU 18: val 1686 ena 12162202 run 12162202 > > > > $perf report --stdio --socket-filter 0 > > > > # To display the perf.data header info, please use --header/--header- > only options. > > # > > # > > # Total Lost Samples: 0 > > # > > # Samples: 17K of event 'cycles' > > # Event count (approx.): 10119095556 > > # Processor Socket: 0 > > # > > # Overhead Command Shared Object Symbol > > # ........ ............ ................... > > .................................. > > # > > 97.68% tchain_edit tchain_edit [.] f3 > > 0.07% tchain_edit tchain_edit [.] f2 > > 0.04% swapper [kernel.vmlinux] [k] run_timer_softirq > > 0.04% swapper [kernel.vmlinux] [k] find_busiest_group > > > > # Samples: 0 of event 'uncore_imc_1/cas_count_read/C' > > # Event count (approx.): 0 > > # Processor Socket: 0 > > # uncore_imc_1/cas_count_read/C: 35937 > > I think we'll need special output/display for non sampling events, > something like extra window in TUI and distinguished output in stdio, the > above is hacked sampling output ;-) I think it depends on what way we finally use. If we use the way which merging perf.data from perf stat and record, I think we need special output for the data from perf stat in TUI/stdio. But if we use the way counter read (:C), I think the best place to show the counter read results is the header/title (just like the patch did). Because the results are the aggregate counts during the whole sampling process. Something like, # Event count: 35937 of event 'uncore_imc_1/cas_count_read/C' Thanks, Kan -- 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/
