On Mon, Apr 19, 2021 at 09:03:18PM +0800, Yicong Yang wrote:
On 2021/4/17 21:56, Alexander Shishkin wrote:
Yicong Yang yangyicong@hisilicon.com writes:
The reason for not using perf is because there is no current support for uncore tracing in the perf facilities.
Not unless you count
$ perf list|grep -ic uncore 77
these are uncore events probably do not support sampling.
I tried on x86:
# ./perf record -e uncore_imc_0/cas_count_read/ Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (uncore_imc_0/cas_count_read/). /bin/dmesg | grep -i perf may provide additional information.
For HiSilicon uncore PMUs, we don't support uncore sampling:
'The current driver does not support sampling. So "perf record" is unsupported. ' [1]
and also in another PMU:
'PMU doesn't support process specific events and cannot be used in sampling mode.' [2]
[1] Documentation/admin-guide/perf/hisi-pmu.rst [2] Documentation/admin-guide/perf/arm_dsu_pmu.rst
I did some debugging for this, and yes, it's related with the event doesn't support sampling for these x86 uncore events.
So I can use below commands for the uncore event 'uncore_imc/data_reads/' in my experiment:
# perf record -e 'uncore_imc/data_reads/' --no-samples -- ls # perf stat -e 'uncore_imc/data_reads/' -- ls
For your case, I think you need to write the callback pmu::event_init(), it should not forbid any tracing even if set sampling, just like other perf event drive for support AUX tracing.
We have our own format of data and don't need perf doing the parsing.
Perf has AUX buffers, which are used for all kinds of own formats.
ok. we thought perf will break the data format but AUX buffers seems won't. do we need to add full support for tracing as well as parsing or it's ok for not parsing it through perf?
IMHO, this could divide into two parts. The first part is to enable perf drive with support AUX tracing, and perf tool can capture the trace data. The second part is to add the decoder in the perf tool so that the developers can *consume* the trace data; for the decoder, you could refer the codes:
tools/perf/util/intel-pt-decoder/ tools/perf/util/cs-etm-decoder/
Or Arm SPE case:
tools/perf/util/arm-spe-decoder/
A similar approach for implementing this function is ETM, which use sysfs for configuring and a character device for dumping data.
And also perf. One reason ETM has a sysfs interface is because the driver predates perf's AUX buffers. Can't say if it's the only reason. I'm assuming you're talking about Coresight ETM.
I am not the best person to give background for this. Mathieu or Mike could give more info for this. From my undersanding, Sysfs nodes can be used as knobs for configuration, but it's difficult for profiling.
Let's think about for the profiling, if one developer uses the Sysfs for the setting and read out the trace data, these informations are discrete. If another developer wants to review the profiling result, then all these info need to be shared together.
So we can benefit much from the perf tool for the usage, since all the profiling context will be gathered (DSOs, hardware configuration which can be saved into metadata), so the final profiling file can be easily shared and more friendly for reviewing.
Thanks, Leo