audio: perf: add core information into performance log #8128
Conversation
btian1
requested review from
pblaszko,
marcinszkudlinski,
dbaluta and
LaurentiuM1234
as code owners
src/schedule/zephyr_domain.c
Outdated
| @@ -84,8 +84,8 @@ static void zephyr_domain_thread_fn(void *p1, void *p2, void *p3) | |||
|
|
|||
| if (++runs == 1 << CYCLES_WINDOW_SIZE) { | |||
| cycles_sum >>= CYCLES_WINDOW_SIZE; | |||
| tr_info(&ll_tr, "ll timer avg %u, max %u, overruns %u", | |||
| cycles_sum, cycles_max, overruns); | |||
| tr_info(&ll_tr, "ll core %u avg %u, max %u, overruns %u", | |||
There was a problem hiding this comment.
we probably want to keep timer after core %u
print out core ID in each core performance log tracing. Signed-off-by: Baofeng Tian <[email protected]>
| tr_info(&ll_tr, "ll timer avg %u, max %u, overruns %u", | ||
| cycles_sum, cycles_max, overruns); | ||
| tr_info(&ll_tr, "ll core %u timer avg %u, max %u, overruns %u", | ||
| core, cycles_sum, cycles_max, overruns); |
There was a problem hiding this comment.
sof-logger used to print a core ID in each line, wondering if it would be a lot of overhead to add that to mtrace too...
There was a problem hiding this comment.
when parsing:
[ 24.203081] ll_schedule: zephyr_domain_thread_fn: ll timer avg 3412, max 6115, overruns 0
CI want to know following data belong to which core, in this line, there is no coreID information, right?
There was a problem hiding this comment.
I think we could add a Kconfig option to add core info to all logs, This could even be a Zephyr side option, but probably easier to add it to SOF side trace macros. I'd keep this 1) kconfig option (as there is bound to be a slight overhead), 2) and keep this short " ". zephyr/include/zephyr/logging/log_core.h shows how this is done to add the "" et al log level prefixes (in a way that can be kconfig'ed out.
But that's an option. Would require some experiments to see how this impacts overall logging overhead. If it's too much, then this PR is probably better.
There was a problem hiding this comment.
it is small cost, since only add one more var print per second, add Kconfig seems too cautious.
There was a problem hiding this comment.
@btian1 I mean if we add this for ALL logs. We have configs that do not have multiple cores and for these this is just overhead to have core0 in all logs. And e.g. on the Intel platforms, we have to fit all logs in a 4KiB SRAM window so adding overhead might lead to dropping logs when many are sent in bursts. You might want to disable this in Kconfig if you want to enable DBG logs.
print out core ID in each core performance log tracing.