Memory attributes to user space dp module by jsarha · Pull Request #10603 · thesofproject/sof

jsarha · 2026-03-05T20:13:03Z

Pass current DP memory attributes to the user-space DP thread.

This implementation does not do anything before we have thesofproject/linux#5537 merged (and before that we should merge #10544).

So quite a few conditions before CI can get any hold of this. I'll mark this as draft for now, even if the implementation is mostly complete. FYI @lyakh , @kv2019i , @lgirdwood.

wjablon1 · 2026-03-06T11:49:21Z

 			return NULL;
 	}
 #endif
+	const struct module_ext_init_data *ext_init =


Minor: You could probably pass only dp_data to module_adapter_mem_alloc instead of the entire structure ext_data.
Since the ext_data is 0-initialized, the dp_data pointer is already set to NULL so you probably wouldn't need the "#if":

dp_data is defined only in ipc4 headers, so I think its easiest to keep it behind #if , and keep the module_adapter_mem_alloc() arguments the way they are.

lgirdwood · 2026-03-30T17:20:02Z

@jsarha ping, any update ?

jsarha · 2026-03-31T21:04:57Z

@jsarha ping, any update ?

@lgirdwood this PR does not do anything and it can not be tested before we merge thesofproject/linux#5537 . So I rather keep this as draft until then.

jsarha · 2026-04-15T21:10:51Z

Rebased and tested against rebased thesofproject/linux#5537 . Ready for review.

Copilot

Pull request overview

This PR propagates IPC4 DP memory requirements (stack and heap sizing) into the SOF userspace DP module initialization path, so the DP thread and per-module heap can be sized based on dp_data from the extended init payload.

Changes:

Allow DP task stack size to be taken from IPC4 dp_data->stack_bytes instead of a fixed default.
Allow the DP module heap allocation size to be derived from IPC4 dp_data interim/lifetime heap requirements.
Thread the decoded extended-init (ext_init) info into the module adapter memory allocation path.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
`src/audio/pipeline/pipeline-schedule.c`	Uses IPC4 `dp_data->stack_bytes` to size the DP task stack at creation time.
`src/audio/module_adapter/module_adapter.c`	Uses IPC4 `dp_data` to size the per-module DP heap allocation and passes ext-init data into allocation.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-15T21:14:57Z

+	    mod->priv.cfg.ext_data->dp_data->stack_bytes > 0)
+		stack_size = mod->priv.cfg.ext_data->dp_data->stack_bytes;
+


DP task stack sizing should enforce a minimum (and potentially alignment) rather than blindly accepting any positive dp_data->stack_bytes. If the IPC value is smaller than TASK_DP_STACK_SIZE (or smaller than what Zephyr requires), this can create an undersized stack and lead to runtime crashes; consider clamping with max(TASK_DP_STACK_SIZE, requested) (and/or rejecting too-small values).

Suggested change

mod->priv.cfg.ext_data->dp_data->stack_bytes > 0)

stack_size = mod->priv.cfg.ext_data->dp_data->stack_bytes;

mod->priv.cfg.ext_data->dp_data->stack_bytes > 0) {

size_t requested_stack_size = mod->priv.cfg.ext_data->dp_data->stack_bytes;

if (requested_stack_size > TASK_DP_STACK_SIZE)

stack_size = requested_stack_size;

}

Ack, I think a minimum would be good.

lyakh · 2026-04-16T06:18:21Z

-static struct processing_module *module_adapter_mem_alloc(const struct comp_driver *drv,
-							  const struct comp_ipc_config *config)
+static struct processing_module *
+module_adapter_mem_alloc(const struct comp_driver *drv,


is this needed? Would the added third argument otherwise exceed 100 characters?

If I put "static struct processing_module * module_adapter_mem_alloc(" on the same line and, arguments on top of each other, and align them to ( , then "const struct module_ext_init_data *ext_init" goes over 100 characters. I'll put "static" on separate line, that should be enough.

kv2019i

A few notes inline, please check.

kv2019i · 2026-04-16T09:59:24Z

+	    mod->priv.cfg.ext_data->dp_data->stack_bytes > 0)
+		stack_size = mod->priv.cfg.ext_data->dp_data->stack_bytes;
+


Ack, I think a minimum would be good.

jsarha · 2026-04-20T18:57:50Z

@kv2019i I addressed your comment here.

lgirdwood · 2026-04-21T16:16:31Z

 	/* src-lite with 8 channels has been seen allocating 14k in one go */
 	/* FIXME: the size will be derived from configuration */
-	const size_t buf_size = 20 * 1024;
+	size_t buf_size = 20 * 1024;


can we kconfig this atm.

lgirdwood · 2026-04-21T16:18:11Z


+	if (mod->priv.cfg.ext_data && mod->priv.cfg.ext_data->dp_data &&
+	    mod->priv.cfg.ext_data->dp_data->stack_bytes > 0)
+		stack_size = MAX(mod->priv.cfg.ext_data->dp_data->stack_bytes, 2048);


I would Kconfig and log this size too.

kv2019i

One more q inline, please check.

lyakh · 2026-04-29T06:38:21Z

+	LOG_INF("Allocating %zu byte heap (default %zu) for %#x", buf_size,
+		CONFIG_SOF_USERSPACE_DP_DEFAULT_HEAP_SIZE, config->id);
 	/* Keep uncached to match the default SOF heap! */
+	/* Note that 'align' argumet is ignored by vmh backend */


well, kind of... I see an assertion there. And maybe the idea is, that "nobody" would ever want to have alignment > size. As long as alignment <= size, the VMH will obey that implicitly because allocations are done in (respectively aligned) buckets. But a larger alignment will fail. But I agree, that that assumption doesn't look perfectly reasonable. I might well need to allocate 100 bytes at a page boundary.

The comment was there to explain why I simply won't put buf_size = ALIGN_UP(buf_size, PAGE_SZ) here, instead of making sure the buffer can at least fit the heap prefix.

But now that you mentioned the assert() (I new it was there, but forgot about it), I think I should remove that alignment requirement, since its likely that the asset() fires if a heap smaller than a page is requested.

lyakh · 2026-04-29T06:39:26Z

 	 *       pointers to IPC payload mailbox, so its only valid in
-	 *       functions that called from this function. This why
-	 *       the pointer is set NULL before this function exits.
+	 *       functions that called from this function. This is why


while at it you could also fix "that are called..."

kv2019i

One comment/question from Guennadi in last commit, but otherwise series seems good to me and my concerns addressed.

kv2019i · 2026-05-11T10:26:40Z

+						domain_id 0
+						stack_bytes_requirement		2048
+						interim_heap_bytes_requirement	20480
+						lifetime_heap_bytes_requirement	4096


@jsarha can you check ^^

lgirdwood · 2026-05-13T12:23:06Z

@jsarha can you check CI and rebase. Thanks !

softwarecki · 2026-05-14T13:23:14Z

+	if (config->ipc_extended_init && ext_init && ext_init->dp_data &&
+	    (ext_init->dp_data->lifetime_heap_bytes > 0 ||
+	     ext_init->dp_data->interim_heap_bytes > 0)) {
+		if (ext_init->dp_data->lifetime_heap_bytes > 64*1024*1024 ||


softwarecki · 2026-05-14T13:35:20Z


+config ZEPHYR_DP_SCHEDULER_MIN_STACK_SIZE
+       int "Minimum stack size for DP processing thread"
+       default 512


What is source of this value? Can stack be smaller than the page size?

@softwarecki , That is just from my head when addressing this:
#10603 (comment)
and this
#10603 (comment)

Would you like to change this safetylimit value? Perhaps increase it?

softwarecki · 2026-05-14T13:39:02Z

-	/* FIXME: the size will be derived from configuration */
-	const size_t buf_size = 28 * 1024;
+	size_t buf_size = CONFIG_SOF_USERSPACE_DP_DEFAULT_HEAP_SIZE;
+	size_t lifetime_size = 4096;


Can we move this value to Kconfig instead of hardcoding it? Is this value related to memory page size?

The separate lifetime heap size is not needed anymore now that #10863 is merged.

lgirdwood · 2026-06-19T15:39:54Z

@jsarha ping

jsarha

A new rebased version after merging #10863 will be pushed soon.

jsarha · 2026-06-22T19:43:40Z

-	/* FIXME: the size will be derived from configuration */
-	const size_t buf_size = 28 * 1024;
+	size_t buf_size = CONFIG_SOF_USERSPACE_DP_DEFAULT_HEAP_SIZE;
+	size_t lifetime_size = 4096;


The separate lifetime heap size is not needed anymore now that #10863 is merged.

jsarha · 2026-06-22T21:24:02Z

It seems our main branch does not produce a booting binary ATM, so I could not test this rebased version. That is why I added [DNM] tag in the headline.

jsarha · 2026-06-23T09:43:03Z

Now this works after rebasing on a version from last week,

lyakh · 2026-06-24T07:09:15Z


 static struct vregion *module_adapter_dp_heap_new(const struct comp_ipc_config *config,
+						  const struct module_ext_init_data *ext_init,
 						  size_t *heap_size)


@jsarha an observation: heap_size is never used. This function is called only from one location and there the third argument of this function is unused. If you have to update this series, you could add a commit here (before this one please), or if this version gets merged, a follow-up is also ok.

Move pipeline_comp_dp_task_init() call after module private data initializations so that the struct module_config is available already at pipeline_comp_dp_task_init() init time. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Remove unused heap_size parameter from module_adapter_dp_heap_new() function. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Use IPC module init extended data (the dp_data) to determine DP module heap size when available. Add Kconfig option SOF_USERSPACE_DP_DEFAULT_HEAP_SIZE (default 20480) as fallback when extended init data is not present or does not provide heap sizes. Sanity-check the requested sizes (reject values above 64 MB) and log the allocated heap size. Also pass ext_init through module_adapter_mem_alloc() to module_adapter_dp_heap_new() and fix a minor comment typo. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Use IPC module init extended data (dp_data stack_bytes) to set the DP processing thread stack size when available. Fall back to TASK_DP_STACK_SIZE when ext init data is not present or does not provide a stack size. Add Kconfig option ZEPHYR_DP_SCHEDULER_MIN_STACK_SIZE (default 2048) to enforce a minimum stack size regardless of what the IPC payload requests. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Add a dummy Kconfig definition for SOF_USERSPACE_DP_DEFAULT_HEAP_SIZE so the testbench build can resolve the symbol. The testbench does not use Zephyr, where this option is normally defined, so it needs a local fallback. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Add posix stub headers for <zephyr/logging/log.h> and <zephyr/sys/util.h> so that firmware source files using LOG_ERR, LOG_INF, LOG_WRN, LOG_DBG, KB, or MB can compile in the testbench / posix build without modification. Remove the #ifdef __ZEPHYR__ guard around the <zephyr/logging/log.h> include in sof/trace/trace.h and the <zephyr/sys/util.h> include in sof/common.h so the posix stubs are picked up automatically. The redundant LOG_MODULE_REGISTER / LOG_MODULE_DECLARE definitions in trace.h are removed since the posix stub now provides them. Remove the macros and fix couple of format string issues. Also the tools/logger CMakeList.txt requires some tuning to find the now unconditionally included zephyr/sys/util.h. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

wjablon1 reviewed Mar 6, 2026

View reviewed changes

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from 43000f8 to 3d9b5c4 Compare April 15, 2026 21:00

jsarha marked this pull request as ready for review April 15, 2026 21:11

Copilot AI review requested due to automatic review settings April 15, 2026 21:11

jsarha requested review from dbaluta, kv2019i, lbetlej, lgirdwood, mmaka1, plbossart and ranj063 as code owners April 15, 2026 21:11

jsarha mentioned this pull request Apr 15, 2026

New memory domain logic thesofproject/linux#5537

Open

Copilot started reviewing on behalf of jsarha April 15, 2026 21:12 View session

Copilot AI reviewed Apr 15, 2026

View reviewed changes

lyakh reviewed Apr 16, 2026

View reviewed changes

kv2019i requested changes Apr 16, 2026

View reviewed changes

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch 2 times, most recently from d2578b5 to 8b70073 Compare April 16, 2026 20:56

jsarha mentioned this pull request Apr 17, 2026

userspace: DP: application: switch to vregion #10702

Merged

lgirdwood reviewed Apr 21, 2026

View reviewed changes

kv2019i reviewed Apr 22, 2026

View reviewed changes

Comment thread src/audio/module_adapter/module_adapter.c Outdated

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from 8b70073 to 6bd9aad Compare April 28, 2026 18:46

jsarha requested review from abonislawski and iuliana-prodan as code owners April 28, 2026 18:46

lyakh reviewed Apr 29, 2026

View reviewed changes

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from 6bd9aad to 34a2c67 Compare April 29, 2026 15:57

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from a103d37 to 4b50cac Compare May 8, 2026 12:10

kv2019i approved these changes May 11, 2026

View reviewed changes

jsarha requested a review from singalsu as a code owner May 12, 2026 15:21

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch 2 times, most recently from 77ba618 to 362854c Compare May 12, 2026 20:04

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from 362854c to 0bb25e7 Compare May 13, 2026 16:33

softwarecki reviewed May 14, 2026

View reviewed changes

jsarha mentioned this pull request May 28, 2026

[DNM] vregions phase II: Actually use the lifetime allocations and make the memory division between lifetime and interim dynamic #10783

Draft

jsarha commented Jun 22, 2026

View reviewed changes

jsarha changed the title ~~Memory attributes to user space dp module~~ [DNM] Memory attributes to user space dp module Jun 22, 2026

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from 0bb25e7 to 6f74d9b Compare June 22, 2026 21:22

jsarha added the DNM Do Not Merge tag label Jun 22, 2026

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from 6f74d9b to a8ccee9 Compare June 23, 2026 09:41

jsarha changed the title ~~[DNM] Memory attributes to user space dp module~~ Memory attributes to user space dp module Jun 23, 2026

jsarha removed the DNM Do Not Merge tag label Jun 23, 2026

lyakh approved these changes Jun 24, 2026

View reviewed changes

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from a8ccee9 to 81e9909 Compare June 25, 2026 13:01

Jyri Sarha added 4 commits June 25, 2026 17:02

module-adapter: module_adapter_dp_heap_new() remove heap_size parameter

30e2ec5

Remove unused heap_size parameter from module_adapter_dp_heap_new() function. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from 81e9909 to 5e259b9 Compare June 25, 2026 14:28

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from 54d2201 to 55e8d71 Compare June 30, 2026 19:23

jsarha force-pushed the memory_attributes_to_user_space_dp_module branch from 55e8d71 to 2a53dfe Compare June 30, 2026 19:56

		mod->priv.cfg.ext_data->dp_data->stack_bytes > 0)
		stack_size = mod->priv.cfg.ext_data->dp_data->stack_bytes;

-	    mod->priv.cfg.ext_data->dp_data->stack_bytes > 0)
-		stack_size = mod->priv.cfg.ext_data->dp_data->stack_bytes;
+	    mod->priv.cfg.ext_data->dp_data->stack_bytes > 0) {
+		size_t requested_stack_size = mod->priv.cfg.ext_data->dp_data->stack_bytes;
+		if (requested_stack_size > TASK_DP_STACK_SIZE)
+			stack_size = requested_stack_size;
+	}

Uh oh!

Conversation

jsarha commented Mar 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsarha Apr 16, 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!

lgirdwood commented Mar 30, 2026

Uh oh!

jsarha commented Mar 31, 2026

Uh oh!

jsarha commented Apr 15, 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!

Copilot AI Apr 15, 2026

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 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jsarha commented Apr 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsarha Apr 29, 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!

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lgirdwood commented May 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsarha Jun 22, 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!

lgirdwood commented Jun 19, 2026

Uh oh!

jsarha left a comment

jsarha Apr 16, 2026 •

edited

Loading

jsarha Apr 29, 2026 •

edited

Loading

jsarha Jun 22, 2026 •

edited

Loading