[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