[FEATURE] Support for scheduling long period tasks

[ranj063]

Is your feature request related to a problem? Please describe.
How do we support a pipeline with deep-buffering requirement connected to the mixer-dai pipeline that runs every 1ms.

This is required to support the multi-stream feature that needs pipeline with variable period sizes connected via mixer to the DAI.

[ranj063]

@lyakh @kv2019i @lgirdwood @plbossart FYI

[lgirdwood]

@lenghonglin fyi

[lenghonglin]

@lenghonglin fyi

At first, From a design perspective, i think the task->startcalculation method should stay the same.

At Second, For my application scenario, I assumed audio formats of 16K,16bit,1ch, period_byte of 1KB, and almost 30ms. So this means I can execute pipe-task in less than 30ms. If long Period Tasks are not supported, this will slow down the CPU to do unnecessary work. In addition, I would like to be able to set period_bytes through the topology so that the sampling period can be configured more flexibly.

At third, my xtensa core not only run sof framework , there are other task need to run , though it not important than sof , but if not support long period tasks, it mean the other task hardly to be schedue.

[lgirdwood]

So the Low Latency (LL) scheduler is designed for simple 1ms periodic synchronous work with tghe following rules

1. tasks cannot be preempted.
2. all tasks must execute in less than the 1ms time slice.

Providing 1 & 2 hold then we can execute less frequent tasks at any period.

This does not scale when the workload takes > 1 ms to execute and hence means we need to use a different scheduler algorithm for longer and higher latency work (aka the "EDF" preemptive scheduler on SOF xtos).

The xtos "EDF" preemptive on xtos could only support 1 priority and scheduling > 1 EDF task was non deterministic (i.e. we wold not guarantee execution order or scheduling start time). This all changes with Zephyr as all the old EDF preemptive tasks would be Zephyr preemptable threads (running with different priorities), there will also be more advanced scheduling available later too, but using the Zephyr thread preemption is the first step.

[lenghonglin]

So the Low Latency (LL) scheduler is designed for simple 1ms periodic synchronous work with tghe following rules

1. tasks cannot be preempted.
2. all tasks must execute in less than the 1ms time slice.

Providing 1 & 2 hold then we can execute less frequent tasks at any period.

This does not scale when the workload takes > 1 ms to execute and hence means we need to use a different scheduler algorithm for longer and higher latency work (aka the "EDF" preemptive scheduler on SOF xtos).

The xtos "EDF" preemptive on xtos could only support 1 priority and scheduling > 1 EDF task was non deterministic (i.e. we wold not guarantee execution order or scheduling start time). This all changes with Zephyr as all the old EDF preemptive tasks would be Zephyr preemptable threads (running with different priorities), there will also be more advanced scheduling available later too, but using the Zephyr thread preemption is the first step.

The other things is that Can we consider config period_byte by topology?

[plbossart]

The other things is that Can we consider config period_byte by topology?

No. Period_bytes is related to the latency and expected buffering. It's not an indicator of the duration of the processing.

[ranj063]

@lgirdwood are you saying that the EDF tasks in xtos are not preemptible and thats the reason we cannot implement this feature with xtos?

[lgirdwood]

@lgirdwood are you saying that the EDF tasks in xtos are not preemptible and thats the reason we cannot implement this feature with xtos?

Sorry, I'm saying the EDF tasks in xtos are preemptable by LL tasks (as they are IRQ context) but not by other EDF tasks. i.e. all EDF tasks on xtos have the same priority. However on Zephyr we can have preemptable tasks with different priorities (where the scheduler will pick the highest priority task)

[kv2019i]

One PR addressing this was just submitted #7089

[kv2019i]

V2.5 branching this week and feature not ready, moving to v2.6.

[lgirdwood]

Moved to v2.7 as DP multicore wont be upstream in time for v2.6