-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf_cnt: improve avg/peak accuracy for component perf measurements #9664
Conversation
With all patches applied, results look like this:
With logging overhead and HDA ISRs removed, peaks are now in hundreds of DSP cycles. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I see it includes some patches from previous PR which can be rebased.
One thing - can we format align the comp IDs so that all text is aligned for each field. Makes it easier to parse. |
@lgirdwood wrote:
Probably best not to touch the formating as these are already parsed by sof-test/tools/sof_perf_analyzer.py , which also adds the module names (using info from kernel log) and makes this more human readable. E.g:
|
The performance counter results are delivered via the logging subsystem and the logging overhead can interfere with the measurements themselves. To mitigate the impact, only a small set of performance counters should be enabled at the same time in build. To enable this, break the CONFIG_PERFORMANCE_COUNTERS Kconfig option into more fine-grained options and add separate options to enable LL task and audio component performance tracing. Signed-off-by: Kai Vehmanen <[email protected]>
Disable CONFIG_PERFORMANCE_COUNTERS_LL_TASKS and CONFIG_SCHEDULE_LL_STATS_LOG by default in the performance overlay. This reduces logging overhead and makes the component level peak traces more reliable. The logging overhead has minimal impact to reported averages, but can be seen in peak execution measurements. Signed-off-by: Kai Vehmanen <[email protected]>
Implement simple alternate reporting for perf_cnt_average() and task_perf_cnt_avg(). By calling the reporting function only for every other measurement window, the overhead of reporting can be filtered out from data. This mostly affects the peak cycle reporting. For average values reporting has only minimal impact. Signed-off-by: Kai Vehmanen <[email protected]>
On many Intel platforms, the HD-DMA interrupts can interfere with component level performance measurements. Add a comment how to disable the interrupts when doing component performance analysis. Signed-off-by: Kai Vehmanen <[email protected]>
eabf5a9
to
cc4a331
Compare
#9661 merged, rebased this PR, marking ready for review. |
@@ -1,7 +1,10 @@ | |||
CONFIG_PERFORMANCE_COUNTERS=y | |||
CONFIG_PERFORMANCE_COUNTERS_COMPONENT=y | |||
CONFIG_PERFORMANCE_COUNTERS_LL_TASKS=y | |||
# disable ll task level statistics to reduce logging overhead | |||
#CONFIG_PERFORMANCE_COUNTERS_LL_TASKS=y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, perf_overlay.conf is for performance monitoring, not for performance enhancement (why would you not have enhanced performance in your default configuration), right? The name sounds potentially a bit confusing, can we rename it? Or at least add a comment at the top
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem to rename it. I don't think we have CI builds and tests with it. It was planned but our plans got changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine as it is, this feature is for performance monitoring but it can have impact on peak when logging.
Build on top of #9661 and improve the PERFORMANCE_COUNTERS infrastructure:
Marking as draft as this requires #9661 to be merged first.