audio: pipeline: change locking strategy for user LL builds by kv2019i · Pull Request #10957 · thesofproject/sof

kv2019i · 2026-06-25T15:23:15Z

A set of patches to change the locking approach for LL audio pipeline scheduling when SOF is built to run all LL pipelines in user-space. The target is to simplify the design and decrease the syscall overhead during typical audio use-cases.

Tested as part of #10558

kv2019i · 2026-06-25T15:23:54Z

Keeping as drafts until dependencies are marged and will then update this PR and mark as ready for review.

kv2019i · 2026-06-25T16:09:38Z

V2 pushed:

quick modification to remove the dependency to lock granting PR, now can mark this ready for review

Copilot

Pull request overview

This PR changes how mutual exclusion is enforced between the IPC thread and the low-latency (LL) pipeline scheduling path when SOF is built to run LL pipelines in Zephyr user-space, aiming to simplify locking and reduce syscall overhead.

Changes:

Keep the LL scheduler mutex held while executing LL tasks in user-space LL builds, shifting protection to a single scheduler-level lock.
Introduce user_ll_lock_sched() / user_ll_unlock_sched() as a shared locking API for IPC-side operations that must exclude the LL thread.
Remove the per-component list mutex and update IPC/pipeline graph operations to use the LL scheduler lock instead.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/schedule/zephyr_ll.c	Holds the scheduler lock while running LL tasks in user-space builds; adds exported scheduler lock/unlock helpers.
src/ipc/ipc4/helper.c	Uses the scheduler lock to protect pipeline/module free and updates LL blocking macros to accept src/dst cores.
src/ipc/ipc-helper.c	Uses the scheduler lock (user-space builds) instead of IRQ disable/enable when freeing components and manipulating buffer lists.
src/include/sof/schedule/ll_schedule_domain.h	Declares the new `user_ll_lock_sched()` / `user_ll_unlock_sched()` APIs.
src/include/sof/audio/component.h	Removes the user-space-only per-component list mutex.
src/audio/pipeline/pipeline-stream.c	Adds scheduler locking around `pipeline_copy()` in user-space LL builds.
src/audio/pipeline/pipeline-graph.c	Switches connect/disconnect list protection to the scheduler lock (or IRQ disable in kernel builds).

Copilot

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

kv2019i · 2026-06-26T12:36:47Z

V2 and V3 pushed:

remove the redundant lock calls and turn them into asserts
fix typos in code comments

lyakh · 2026-06-29T07:51:39Z

 #include <stdbool.h>
 #include <stddef.h>
 #include <stdint.h>
+#include <sof/schedule/ll_schedule_domain.h>


one too many

Removed in V4.

lyakh · 2026-06-29T07:53:29Z

-		assert(ret == 0); \
-	} while (0)
+#define PPL_LOCK(x) user_ll_assert_locked(x)
+#define PPL_UNLOCK(x)


so PPL_UNLOCK() doesn't need the argument?

Hmm, yes, stricly not needed. Can drop in next version. UPDATE: done in V4.

lyakh · 2026-06-29T08:50:46Z

-#define ll_unblock(cross_core_bind, flags)	irq_local_enable(flags)
+#if CONFIG_SOF_USERSPACE_LL
+/* note: cross-core streams are disabled in the build in this branch,
+ * so we can safely use 'src_core' only */


could explicitly add a comment that src_core == dst_core

Done in V4.

lyakh · 2026-06-29T09:12:51Z

+#else
+static inline void zephyr_ll_lock_acquired(int core) { (void)core; }
+static inline void zephyr_ll_lock_releasing(int core) { (void)core; }
+#endif /* CONFIG_ASSERT */


to the commit description - sorry, couldn't quite follow how it describes this commit. Could you point out where the lock is taken for the whole duration of the LL tick processing? That's what the commit description is saying, right?

@lyakh ack, I should merge patches 2 and 3. The actual lock is taken in patch 2, should be merged. Will fix.

Actually, I kept these as separate patches (one for scheduler, one for audio pipeline code), but reworded the text in 3rd commit. So 2nd patch changes locking strategy in ll scheduler, 3rd patch removes the now unnecessary locks in audio pipeline level. Changed in V4.

kv2019i · 2026-06-30T21:55:03Z

V4 pushed:

addressed comments so far

Add new functions to lock/unlock the LL scheduler for a given core. This is intended for audio application code that needs to modify the audio pipelines and needs an interface to get exclusive access to the pipelines on a particular core. This interface is specific to SOF builds with CONFIG_SOF_USERSPACE_LL. If LL scheduler is running in kernel space, there is option to disable interrupts for similar effect. For now these code paths are kept separate. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

In user-space LL builds (CONFIG_SOF_USERSPACE_LL), the IPC user thread cannot block interrupts while making modifications to the audio graph. To workaround this limitation, one could either protect each pipeline object with locks, or keep the LL level lock held while executing LL tasks. This patch implements support for the latter approach. If building SOF for user LL, do not release the lock when running a task. This will help to reduce number of syscalls during a LL iteration, while still allowing to safely implement IPC handlers that need to modify the audio graph. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

Modify the locking approach for CONFIG_SOF_USERSPACE_LL builds. Kernel LL implementation heavily relies on ability to disable interrupts when IPC handler is modifying the graph. This ensures a new LL tick and execution of a new graph cycle does not start before the graph modifications done by IPC handler are complete. In user-space, this approach is not available as user-space thread cannot disable interrupts. In commit 1e59ce2 ("pipeline: protect component connections with a mutex"), a sys_mutex based locking was implemented to protect the component list and modifications to it. This approach does not scale in the end as this would require taking the mutex for each component of each pipeline, and take the locks on every LL cycle tick. This results in significant system call overhead. Additionally Zephyr sys_mutex does not work correctly if the lock object is put into dynamically allocated user memory. The LL scheduler logic was changed to keep the LL lock when building with CONFIG_SOF_USERS_SPACE. A single lock is used to protect the whole LL graph, and the lock is taken at start of LL tick. Take benefit of this in audio pipeline code and remove redundant locking. The patch only changes behaviour for userspace LL SOF builds. If LL scheduling is kept in kernel, locking is done as before. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

kv2019i · 2026-06-30T22:04:30Z

V5 pushed:

fix a git squash mistake

lyakh · 2026-07-01T06:45:13Z

 #include <sof/audio/module_adapter/module/generic.h>
 #include <sof/audio/pipeline.h>
 #include <sof/ipc/msg.h>
+#include <sof/schedule/ll_schedule_domain.h>


CONFIG_SOF_USERS_SPACE in commit description seems to be wrong

lyakh · 2026-07-01T06:51:59Z

+/* Assert that the calling context already holds the LL lock for 'core'. */
+void user_ll_assert_locked(int core);
+#else
+static inline void user_ll_assert_locked(int core) { (void)core; }


could be ARG_UNUSED(), not important

lyakh · 2026-07-01T06:55:46Z

+#if CONFIG_SOF_USERSPACE_LL
+/* note: cross-core streams are disabled so src_core==dst_core */
+#define ll_block(src_core, dst_core, flags)	do { user_ll_lock_sched(src_core); (void)flags; } while(0)
+#define ll_unblock(src_core, dst_core, flags)	do { user_ll_unlock_sched(src_core) ; (void)flags; } while(0)


also ARG_UNUSED() and also unimportant

lyakh · 2026-07-01T07:10:48Z

+#ifdef CONFIG_SOF_USERSPACE_LL
+	ppl_core = icd->core;
+	user_ll_lock_sched(ppl_core);
+#endif


currently this is working with no locking at all, right? Theoretically this could race against pipeline streaming if we have a forking graph where one branch is stopped and freed while the other one is still running, correct? So I suppose we have a guard in place that would prevent the streaming loop from entering the stopped branch safely somehow?

kv2019i force-pushed the 202606-ll-locking-change branch 2 times, most recently from f1b280d to 1998a42 Compare June 25, 2026 16:07

kv2019i changed the title ~~audio: pipeline: change locking strategy for user LL builds (depends on PR10821)~~ audio: pipeline: change locking strategy for user LL builds Jun 25, 2026

kv2019i marked this pull request as ready for review June 25, 2026 16:09

Copilot AI review requested due to automatic review settings June 25, 2026 16:09

kv2019i requested review from LaurentiuM1234, bardliao, dbaluta, lbetlej, lgirdwood, marcinszkudlinski, mmaka1, pblaszko, plbossart and tmleman as code owners June 25, 2026 16:09

Copilot started reviewing on behalf of kv2019i June 25, 2026 16:11 View session

Copilot AI reviewed Jun 25, 2026

View reviewed changes

Comment thread src/schedule/zephyr_ll.c Outdated

Comment thread src/ipc/ipc-helper.c Outdated

Comment thread src/audio/pipeline/pipeline-stream.c Outdated

Comment thread src/schedule/zephyr_ll.c Outdated

Comment thread src/schedule/zephyr_ll.c Outdated

kv2019i requested review from abonislawski, Copilot, serhiy-katsyuba-intel, softwarecki and wjablon1 June 25, 2026 16:38

Copilot started reviewing on behalf of kv2019i June 25, 2026 16:38 View session

Copilot AI reviewed Jun 25, 2026

View reviewed changes

Comment thread src/schedule/zephyr_ll.c Outdated

Comment thread src/audio/pipeline/pipeline-stream.c Outdated

Comment thread src/ipc/ipc-helper.c

kv2019i force-pushed the 202606-ll-locking-change branch 2 times, most recently from 0705e81 to cb4edfd Compare June 26, 2026 12:36

lyakh reviewed Jun 29, 2026

View reviewed changes

kv2019i force-pushed the 202606-ll-locking-change branch from cb4edfd to a57c14b Compare June 30, 2026 21:54

kv2019i added 3 commits July 1, 2026 01:03

kv2019i force-pushed the 202606-ll-locking-change branch from a57c14b to 2a36aba Compare June 30, 2026 22:04

lyakh approved these changes Jul 1, 2026

View reviewed changes

Uh oh!

Conversation

kv2019i commented Jun 25, 2026

Uh oh!

kv2019i commented Jun 25, 2026

Uh oh!

kv2019i commented Jun 25, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kv2019i commented Jun 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kv2019i Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kv2019i commented Jun 30, 2026

Uh oh!

kv2019i commented Jun 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

kv2019i Jun 30, 2026 •

edited

Loading