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

[AlexandrY]

По сему я остановился на варианте т.н. pool памяти, но таких пулов не один, а несколько - каждый имеел различный размер кусочков (slice).
Так же был диспетчер всех этих пулов, который сам выбирал при захвате пул с наиболее подходящим размером кусочка.

Работало вполне эффективно.

Как вы, интересно, определили его эффективность.
Как то не приходилось видеть движков которые бы сами эффективно могли бы создавать правильные распределения пулов фиксированного размера.
Да и сомнительно насчет сбора статистики. Сама такая статистика требует heap-а неопределенного размера.
А если все таки статистика была компактной, то какой смысл был ее собирать, анализ исходников ответил бы на все вопросы.

[Forger]

Как вы, интересно, определили его эффективность.

А не помню я, делал для своего развития, это никуда потом не пошло.
Вроде как проверял по макс. временам захвата/освобождения блоков и их частоты использования.

Вообще, в моих реальных проектах это нафик не было нужно: я просто закладываю больше памяти.
Так выходит быстрее, проще и надежнее А цена ОЗУ? Так в моих проектах она вообще некритична - мелкосерийные изделия, епта.

Как то не приходилось видеть движков которые бы сами эффективно могли бы создавать правильные распределения пулов фиксированного размера.
Да и сомнительно насчет сбора статистики. Сама такая статистика требует heap-а неопределенного размера.

Да не было там чего-то заумного, просто алгоритм был ориентирован на минимизацию использования памяти самим приложением.
К сожалению, не сохранились те исходники...

А если все таки статистика была компактной, то какой смысл был ее собирать, анализ исходников ответил бы на все вопросы.

Мне кажется, что анализ исходников не даст полной картины в многопоточном приложении, в динамике.
Но анализ кода даст точную картину при статических объектах, да и это сам компилятор/линкер дает