Аллокатор для Cortex-M3, лучшая стратегия выделения памаяти? Опции

[brag]

Как ни крути, а динамическая память всеравно рано или поздно становится необходимой...
Готовые реализации использовать не могу по многим причинам(необходимость иметь несколько арен, thread-safety итп).
Нужен аллокатор, который будет давать минимальную фрагментацию в реальных условиях,минимальный обьем служебной памяти, производительность не особо важна, тк размер арены от силы 32кб.

Реальные условия - одни блоки памяти живут практически forever, другие выделяются/освобождаются подобно стековым переменным - в начале/конце функции соответственно. Блоки разной длины, от 16 до 1024 байт, редко больше. Юзать стек для этого не канает, тк нужно резервировать большие стеки для каждого потока, а это память будет использована на 5-10% в 90% времени.
В основном такое поведение имеет место в GUI и всяких обменах сообщениями, где сами алгоритмы гораздо тяжелее, чем аллокатор.

Пока сделал классическую реализацию best-fit, из служебных полей только размер,бит free/used в начале и в конце блока для облегчения free() и слияния соседних пустых блоков, тобышь заголовок весит 8 байт. Работает все гуд, но хз как оно будет при длительной работе девайса(ну там месяц,2,3).
Курил всякие разные реализации, но там делается упор в основном на производительность, а про фрагментацию редко где упоминается.
По рандом-бенчмаркам best-fit типа рулит, но смущает его тенденция к накоплению кучи маленьких(малоюзабельных) блоков.
First-fit, даже на простых тестах в моих реальных условиях показал гораздо худшую фрагментацию, чем best-fit. next-fit еще хуже.

Если кто-то имел дело с использованием,разработкой аллокаторов - буду благодарен за любую информацию...

[brag]

Чистый стек не идет. Потоков много, вызывающих одни и те же функции. в этих функциях выделяются освобождаются блоки подобно автоматическим переменным. На стеке их создавать нельзя - нужны большие стеки для каждого потока. В общем стеке тоже не идет - потоки работают асинхронно.
Куча надо по-любому, но какая-то хитрая, шоб и кучу мелких фрагментов не плодила и памяти много не жрала

[neiver]

Чистый стек не идет. Потоков много, вызывающих одни и те же функции. в этих функциях выделяются освобождаются блоки подобно автоматическим переменным.

При таком использовании может подойти аллокатор, который выделяет память последовательно из пула фиксированного размера и не освобождает её. Освобождается весь пул при выходе из функции. А пулы памяти можно выделять, например, с помощью bitmap allocator.