Аллокатор для 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]

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

[jcxz]

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

Раз у вас не хватает памяти чтобы распределить её в виде static или на стеке для всех потоков, значит возможна ситуация (и даже с большей вероятностью), когда много потоков запросит больше памяти чем есть. С наличием служебных полей управления блоками в heap и фрагментации это даже более вероятно, чем при static размещении.
Что ваша система должна делать при этом? Выдать отказ потоку (но значит алгоритм всех потоков должен рассчитывать, что может быть получен отказ в памяти)? Или приостановить выполнение потока (но может случиться dead-lock)?

Я полностью согласен с Forger - делаю так же - стараюсь обходиться static. Если невозможно - использую динамическое выделение блоков фиксированной длины. Даже в довольно сложных проектах с многими потоками нигде не использую стандартный heap.
Также помогает знание алгоритма работы потоков: где-то можно использовать union если нет одновременного использования памяти, где-то можно ставить семафоры на функции использующие большие блоки статической памяти и т.п.