carlocaione
commented
3 years ago I'm not entirely clear whether your proposal is involving to extend the current heap / slab /pools APIs to directly support allocation of memory blocks on cacheable / non-cacheable memory.
The point is that FWICT all the current allocators do already have the capability to locate the the buffer area for heap/slab/pool in a code-provided memory region with the desired attributes, so the solution to this problem is solved at compile time by providing the appropriate object (in the appropriate memory region) to the allocator (see for example the mem parameter of k_heap_init()).
So the problem actually moves from extending the allocators API to actually extend (for example) the memory domain API so that we can actually query the arch code to provide / return the memory region with the correct attributes so that we can use that for the memory allocators.
The problem is whether all the interested architectures already implement the memory domain API (like the MMU-enabled architectures) or whether we should use some other API to query the attributes of the memory regions.
Introduction
We would like to have an API that allows for static and/or dynamic allocation of memory blocks on cache-able and/or non-cacheable memory.
Problem description
Allocation of cache-able and non-cachable memory is currently not supported in Zephyr, in a generic way.
Some architectures (e.g. Cortex-M) have some arch-level support for defining non-cacheable linker/memory sections and "allocate" them e.g. to drivers, but this is done below the kernel and is not exposed as a kernel service.
We would like to have ability to allocate and de-allocate memory, using the current standard ways offered by the Zephyr kernel, that may belong to either cacheable or non-cacheable regions.
This should ideally involve all options - slab, heap, pools, etc.
As a side comment we should have the ability to allocate blocks that are aligned to cache boundaries for cached memory.
Dependencies
A dependency is the underlined ARCH-level implementation for memory attribution with respect to cache-ability. We probably need to design cache-able and non-cachable memory regions, from which we can allocate cache-able and non-cacheable memory blocks. There might be limitations of ARCH hardware resources (e.g. MPU) that will have an impact on the design/implementation.