You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE] Support for scheduling long period tasks #5966
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.
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.
So the Low Latency (LL) scheduler is designed for simple 1ms periodic synchronous work with tghe following rules
tasks cannot be preempted.
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.
So the Low Latency (LL) scheduler is designed for simple 1ms periodic synchronous work with tghe following rules
tasks cannot be preempted.
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?
@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)
Activity
ranj063 commentedon Jun 29, 2022
@lyakh @kv2019i @lgirdwood @plbossart FYI
lgirdwood commentedon Jun 30, 2022
@lenghonglin fyi
ASoC: SOF: Intel: enable dmic handling with 2 or fewer SoundWire links
hlleng commentedon Jul 4, 2022
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 commentedon Jul 4, 2022
So the Low Latency (LL) scheduler is designed for simple 1ms periodic synchronous work with tghe following rules
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.
hlleng commentedon Jul 5, 2022
The other things is that Can we consider config
period_byteby topology?plbossart commentedon Jul 5, 2022
No. Period_bytes is related to the latency and expected buffering. It's not an indicator of the duration of the processing.
ranj063 commentedon Jul 5, 2022
@lgirdwood are you saying that the EDF tasks in xtos are not preemptible and thats the reason we cannot implement this feature with xtos?
ASoC: SOF: Intel: enable dmic handling with 2 or fewer SoundWire links
lgirdwood commentedon Jul 6, 2022
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)
ASoC: SOF: Intel: enable dmic handling with 2 or fewer SoundWire links
ASoC: SOF: Intel: enable dmic handling with 2 or fewer SoundWire links
ASoC: SOF: Intel: enable dmic handling with 2 or fewer SoundWire links
4 remaining items
kv2019i commentedon Feb 15, 2023
One PR addressing this was just submitted #7089
kv2019i commentedon Mar 6, 2023
V2.5 branching this week and feature not ready, moving to v2.6.
lgirdwood commentedon May 10, 2023
Moved to v2.7 as DP multicore wont be upstream in time for v2.6
kv2019i commentedon Dec 17, 2025
We have DP implemented now, so this is done. FYI @ranj063