zephyr: ll_scheduler: fix a recent regression

[lyakh]

Fixes a regression introduced by #3768

[keyonjie]

so here Zephyr uses a different overhead with XTOS, @lyakh why 1ms overhead needed with Zephyr?

[lyakh]

so here Zephyr uses a different overhead with XTOS, @lyakh why 1ms overhead needed with Zephyr?

@keyonjie this isn't an overhead, CONFIG_SYSTICK_PERIOD was a period as the name suggests, and it was in microseconds, i.e. it was 1000us. Then it was passed in a parameter, called timeout, which already confused things. Then ticks_tout was effectively calculated as a system tick period in clock ticks. It had nothing to do with scheduling overhead.

[keyonjie]

so here Zephyr uses a different overhead with XTOS, @lyakh why 1ms overhead needed with Zephyr?

@keyonjie this isn't an overhead, CONFIG_SYSTICK_PERIOD was a period as the name suggests, and it was in microseconds, i.e. it was 1000us. Then it was passed in a parameter, called timeout, which already confused things. Then ticks_tout was effectively calculated as a system tick period in clock ticks. It had nothing to do with scheduling overhead.

So what does the 'K_CYC(ticks_delta - ZEPHYR_SCHED_COST)' in below code mean? does it ask for a scheduling after this cycles? I still cannot understand why we need to add a 1ms LL_TIMER_PERIOD to this ticks_delta there.

	ret = k_work_reschedule_for_queue(&zephyr_domain->ll_workq[core],
&zdata[core].work,
K_CYC(ticks_delta - ZEPHYR_SCHED_COST));

[kv2019i]

@lyakh and @lgirdwood I can verify this fix helped to get our sof-test results back up -- without this patch, there were 14 new failures in sof-test all. With this fix, we are back to expected results.

@keyonjie As far as I understand the code, ZEPHYR_SCHED_COST is an estimate of how long it takes to schedule next run and this should be taken into consideration when calculation the delay. E.g. without this, the next run of zdata[core].work would be run ZEPHYR_SCHED_COST cycles too late.

We are looking at a simpler system where we'd have just simple repeating 1ms (using zephyr timer interface) run of the audio pipeline and not try to reprogram the delay every time. There are pros and cons in this approach as well, so for now, let's stick to the current scheduler.

[lgirdwood]

Zephyr schedules on kernel ticks not on hardware clock cycles, so this was to try and align the tick to cycle. We have 50k kernel ticks per second, however this could be aligned to 48k ticks if it makes the math easier.

[keyonjie]

@kv2019i@lgirdwood thanks for information, my question is that adding 1ms LL_TIMER_PERIOD to this ticks_delta (and eventually to the Zephyr scheduler) could lead to the scheduling happen too late, then Xrun could happen more easily when running more pipelines simultaneously, this was the reason why I refined this part for timer_domain previously.

[lgirdwood]

@kv2019i@lgirdwood thanks for information, my question is that adding 1ms LL_TIMER_PERIOD to this ticks_delta (and eventually to the Zephyr scheduler) could lead to the scheduling happen too late, then Xrun could happen more easily when running more pipelines simultaneously, this was the reason why I refined this part for timer_domain previously.

Agreed, lets refine and fix.