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
The SOF heap allocations are multi-purpose with distinct features:
they can be cached or uncached
there is a special allocation type for memory, that will never be freed back. Those allocations also panic if they fail
there is an allocation type for larger memory block, e.g. for audio buffers
some of those allocation types also initialise memory with 0s
Work is currently underway to simplify and make those allocations more robust. I'd like to consider several more changes:
convert some of init-time no-free allocations to static objects in .data or .bss
re-consider whether all 0-initialised allocations really need that. In particular large-size / buffer type allocations do that unconditionally, and it appears likely to me, that e.g. audio buffers will be completely overwritten with audio data so such initialisations have no value.
Activity
lgirdwood commentedon Oct 13, 2021
@lyakh this should be focused into the Zephyr integration - dont want to spend any effort on the SOF allocator.
kv2019i commentedon Dec 17, 2025
@lyakh @lgirdwood This seems completely out-of-date.