On 27/04/2021 19:24, James Clark wrote:
On 21/04/2021 15:04, Daniel Kiss wrote:
This series adds a feature to ETR-PERF that sync the ETR buffer to perf periodically. This is really handy when the system wide trace is used because in this case the perf won't sync during the trace. In a per-thread setup the traced program might not go to the kernel frequvently enought to collect trace. Polling helps in both usecases. Can be used with strobing. Tuning polling period is challanging, I'm working on an additional patch that adds some metrics to help tune the polling period.
Hi Daniel,
Is the expectation that leaving the polling period at 0 should have no affect on the amount of data collected vs not using this patch?
I've been running the octane 2 benchmark on Chrome on Juno and get these results:
No patch: I consistently get 130MB of trace across dozens of runs. Patch, polling = 0: Run 1 - 6.1MB Run 2 - 4.7MB
Sorry, these small files are because there is no AUXTRACE event at all, only built in events. It's not small because less trace was collected.
Patch, polling = 100: 1600MB
Thanks James
Daniel Kiss (4): coresight: tmc-etr: Advance buffer pointer in sync buffer. coresight: tmc-etr: Track perf handler. coresight: etm-perf: Export etm_event_cpu_path. coresight: Add ETR-PERF polling.
.../testing/sysfs-bus-coresight-devices-tmc | 8 + drivers/hwtracing/coresight/Makefile | 2 +- .../hwtracing/coresight/coresight-etm-perf.c | 10 +- .../hwtracing/coresight/coresight-etm-perf.h | 1 + .../coresight/coresight-etr-perf-polling.c | 316 ++++++++++++++++++ .../coresight/coresight-etr-perf-polling.h | 42 +++ .../hwtracing/coresight/coresight-tmc-core.c | 2 + .../hwtracing/coresight/coresight-tmc-etr.c | 22 +- drivers/hwtracing/coresight/coresight-tmc.h | 2 + 9 files changed, 401 insertions(+), 4 deletions(-) create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.h