mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-08-30 10:35:21 +00:00
aa4227754c
The existing mem_pool implementation has been an endless source of frustration. It's had alignment bugs, it's had racy behavior. It's never been particularly fast. It's outrageously complicated to configure statically. And while its fragmentation resistance and overhead on small blocks is good, it's space efficiencey has always been very poor due to the four-way buddy scheme. This patch introduces sys_heap. It's a more or less conventional segregated fit allocator with power-of-two buckets. It doesn't expose its level structure to the user at all, simply taking an arbitrarily aligned pointer to memory. It stores all metadata inside the heap region. It allocates and frees by simple pointer and not block ID. Static initialization is trivial, and runtime initialization is only a few cycles to format and add one block to a list header. It has excellent space efficiency. Chunks can be split arbitrarily in 8 byte units. Overhead is only four bytes per allocated chunk (eight bytes for heaps >256kb or on 64 bit systems), plus a log2-sized array of 2-word bucket headers. No coarse alignment restrictions on blocks, they can be split and merged (in units of 8 bytes) arbitrarily. It has good fragmentation resistance. Freed blocks are always immediately merged with adjacent free blocks. Allocations are attempted from a sample of the smallest bucket that might fit, falling back rapidly to the smallest block guaranteed to fit. Split memory remaining in the chunk is always returned immediately to the heap for other allocation. It has excellent performance with firmly bounded runtime. All operations are constant time (though there is a search of the smallest bucket that has a compile-time-configurable upper bound, setting this to extreme values results in an effectively linear search of the list), objectively fast (about a hundred instructions) and amenable to locked operation. No more need for fragile lock relaxation trickery. It also contains an extensive validation and stress test framework, something that was sorely lacking in the previous implementation. Note that sys_heap is not a compatible API with sys_mem_pool and k_mem_pool. Partial wrappers for those (now-) legacy APIs will appear later and a deprecation strategy needs to be chosen. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
50 lines
1.7 KiB
Plaintext
50 lines
1.7 KiB
Plaintext
# Copyright (c) 2016 Intel Corporation
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
menu "OS Support Library"
|
|
|
|
config JSON_LIBRARY
|
|
bool "Build JSON library"
|
|
help
|
|
Build a minimal JSON parsing/encoding library. Used by sample
|
|
applications such as the NATS client.
|
|
|
|
config RING_BUFFER
|
|
bool "Enable ring buffers"
|
|
help
|
|
Enable usage of ring buffers. This is similar to kernel FIFOs but ring
|
|
buffers manage their own buffer memory and can store arbitrary data.
|
|
For optimal performance, use buffer sizes that are a power of 2.
|
|
|
|
config BASE64
|
|
bool "Enable base64 encoding and decoding"
|
|
help
|
|
Enable base64 encoding and decoding functionality
|
|
|
|
config SYS_HEAP_VALIDATE
|
|
bool "Enable internal heap validity checking"
|
|
help
|
|
The sys_heap implementation is instrumented for extensive
|
|
internal validation. Leave this off by default, unless
|
|
modifying the heap code or (maybe) when running in
|
|
environments that require sensitive detection of memory
|
|
corruption.
|
|
|
|
config SYS_HEAP_ALLOC_LOOPS
|
|
int "Number of tries in the inner heap allocation loop"
|
|
default 3
|
|
help
|
|
The sys_heap allocator bounds the number of tries from the
|
|
smallest chunk level (the one that might not fit the
|
|
requested allocation) to maintain constant time performance.
|
|
Setting this to a high level will cause the heap to return
|
|
more successful allocations in situations of high
|
|
fragmentation, at the cost of potentially significant
|
|
(linear time) searching of the free list. The default is
|
|
three, which results in an allocator with good statistical
|
|
properties ("most" allocations that fit will succeed) but
|
|
keeps the maximum runtime at a tight bound so that the heap
|
|
is useful in locked or ISR contexts.
|
|
|
|
endmenu
|