Аллокатор для 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 еще хуже.

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

[Forger]

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

Я в свое время заморачивался, даже делал дефрагментатор, но это оказалось ненадежным, потому как в таких системах сложно добится детерменирванного времени захвата/высвобождения куска памяти.
По сему я остановился на варианте т.н. pool памяти, но таких пулов не один, а несколько - каждый имеел различный размер кусочков (slice).
Так же был диспетчер всех этих пулов, который сам выбирал при захвате пул с наиболее подходящим размером кусочка.
Т.е. в каждом пуле кусочки равного размера в пределах самого пула, но у каждого пула свой размер кусочков.
Так же этот диспетчер собирал статистику в рабочем режиме, и пре перезапуске прошивки автоматически создавал пулы с размерами кусочков и их числом на основании статистики последнего сеанса работы прошивки (статистика писалась в eeprom).
Пул-память дает четко детерменированное время захвата/освобождения кусочков.
Да и фрагментация как таковая тут полностью отсутствует.
Работало вполне эффективно.
Потом я это переписал на С++ с использованием smart pointer, стало еще удобнее работать - в коде нигде не было new/delete, куски сами освобождались, если на них уже никто не ссылался. Ориентировалось под применение RTOS, хотя можно и без нее.
А обычная куча со всеми ее недостатками, имхо, во встраиваемых приложениях - капризная и ненадежная вещь, уж лучше тогда взять проц с большим объемом памяти, чем кучу использовать. Я стараюсь избегать кучи в embedded проектах.
Ну как-то так