zephyr: alloc: add 32K virtual heap bucket#10684
zephyr: alloc: add 32K virtual heap bucket#10684abonislawski wants to merge 1 commit intothesofproject:mainfrom
Conversation
The original virtual heap layout used the full 0x100000 region and forced 24 KB DMA buffers to consume 64 KB blocks. Increase the virtual heap region size to 0x140000 and add a 32 KB block pool so medium-sized DMA buffers no longer deplete the 64 KB entries. Signed-off-by: Adrian Bonislawski <adrian.bonislawski@intel.com>
There was a problem hiding this comment.
Pull request overview
Adjusts the Zephyr virtual heap layout to reduce fragmentation and avoid consuming 64 KB blocks for ~24 KB DMA buffers by expanding the shared virtual heap region and adding an intermediate bucket size.
Changes:
- Added a 32 KB block pool to the virtual memory heap buffer configuration.
- Increased the default virtual heap shared region size from
0x100000to0x140000to accommodate the updated bucket layout.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
zephyr/lib/alloc.c |
Adds a 32 KB block bucket to improve fit for medium-sized DMA buffer allocations. |
zephyr/Kconfig |
Expands the default virtual heap region size to support the additional bucket capacity. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| hex "Size in bytes of virtual memory region for virtual heap shared for all cores" | ||
| depends on MM_DRV_INTEL_ADSP_MTL_TLB | ||
| default 0x100000 | ||
| default 0x140000 |
There was a problem hiding this comment.
this adds 256k to VMH. In fact we are going to try and move some of VMH allocations to vregions, for which we might also end up shrinking VMH. If this is for optimisation to avoid using larger blocks, can we keep the total size the same and rebalance buffers? Also I don't understand how saving some of 64k buffers of which there are currently 3, requires adding 8 32k buffers?
There was a problem hiding this comment.
I don't want to rebalance globally here (requires testing all scenarios), we can shrink later if some allocations are moved. And even better, get rid of these blocks in the future. In the current configuration there are not enough 64k blocks which are used inefficiently, and in fact this is already a limited increase from PR 10499 which was too big. I could limit it more to 4x 32 probably.
The original virtual heap layout used the full 0x100000 region and forced 24 KB buffers to consume 64 KB blocks.
Increase the virtual heap region size to 0x140000 and add a 32 KB block pool so medium-sized buffers no longer deplete the 64 KB entries.