[Sound-open-firmware] Zephyr memory allocation from heap
Kai Vehmanen
kai.vehmanen at linux.intel.com
Tue Aug 23 19:06:41 CEST 2022
Hi,
On Tue, 23 Aug 2022, Daniel Baluta wrote:
> Thanks a lot Andy / Guennadi for your answers.
>
> I wonder why SOF rmalloc & friends always force
> the allocations to be aligned with PLATFORM_DCACHE_ALIGN.
this is probably due to sof/zephyr/wrapper.c:rmalloc() and way it
is currently implemented.
The problem in short:
1) we don't want a fixed partition of a cached and uncached heap
- split between cached/uncached usage may vary depending on
use-cases
2) we've implemented rmalloc on top of zephyr/sys_heap that
stores metadata at start of allocated blocks
Now this has the distinct disadvantage (on noncoherent cache arch like
xtensa) that we need to ensure that the metadata (maintained by zephyr
sys_heap) of a block allocated for cached use, does not live on the same
cacheline as blocks allocated noncached, or cached but used by other
cores. IOW, to ensure validity of the heap metadata, we need to align all
allocations to cacheline granularity.
This is not a fundamental limitation, just a property of the current
mapping. There are a number of ways to allow for more effient approach
for small allocations, but each have their own cons:
- separate heaps for cached and noncached
- use something else than sys_heap to implement the heap (e.g.
keep metadata separate from the allocated blocks)
- use per-core heaps
... discussion (and patches :)) are welcome. Thanks Daniel for kicking
this off.
Br, Kai
More information about the Sound-open-firmware
mailing list