1. Вы не очень внимательно посмотрели тексты TLSF в плане многозадачности.
2. Авторы позиционируют свой TLSF как альтернативу другим менеджерам памяти для Linux.

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

Мораль - для специфических требований, специфический аллокатор. Автор ветки ничего специфического не требовал.

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

У boost как есть возможность программно делать пулы для одинакового размера буферов. Буду пробовать tslf...

Секундочку. Там за Вас уже разработчики камня подумали - в том смысле, что MAC DMA уже оперирует связными списками. Посмотрите, как планируемый аллокатор будет дружить с этим DMA и подумайте... Крепко подумайте...

Ваша правда по пункту 1. Там действительно обнаружилось еще пару функций обернутых мьютексами в стиле POSIX.
Недоглядел.
Сам алгоритм TLSF, я конечно уважаю, но это полуфабрикат все таки. Под боевую платформу его еще точить и точить.

Какие требования к малым системам характерны мне кажется я знаю. Портировал uCOS на процы с 2K RAM-а.
Каких и сколько влезет задач в 64K тож как бы представляю. Не разбежишься там.
Человек неминуемо через месяцок будет помнить там все задачи на перечет и даже последовательность их выполнения.
Такое возможно в малых системах и в этом принципиальное отличие от линукса где даже гуру не знают и 10% задач крутящихся в их системе.
В линуксе можно применить статистику, а в малой системе эффективнее может оказаться ручной тюнинг собственно приложения на использование блоков фиксированной длины. (не путать с тюнингом типоразмеров самих блоков менеджера)
Менеджер с блоками фиксированной длины вообще не имеет фрагментации и таким образом гораздо лучше TLSF для малых систем.
И в системе с 64K я думаю это правило еще действует.
Недавно ворочал проект с довольно крупным стеком ZigBee от TI и они там не поленились тюнингировать все приложение и операционку под менеджер с блоками фиксированной длины.
Так что говорить о специфичности таких менеджеров не приходится.

Речь даже не о том кто какого мнения, а о том что если хотите потерять 20K (служебная инфа + неминуемая фрагментация) из 64-х - применяйте TLSF

Никак не могу понять, откуда вы взяли цифру 20К, которую съедает TLSF? Да, там есть накладные расходы на каждый выделяемый блок. Но именно эта дополнительная информация и позволяет минимизировать ту самую фрагментацию, о которой вы говорите. Из статически выделяемых - один массив table[]

Я не агент по продвижению TLSF и привел этот проект как современный и любопытный в своей реализации. Так что "страшилки" про пожираемую им память как-то не очень обоснованы.

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

А я чтоль противник TLSF?
Тока уточняю особенности ее тактического применения

Могу предложить мной писанный менагер.

Главным шагом для написания своего менагера была отладка и контроль того как приложение использует кучю, тобиш что куда и сколько кладет, какое пиковое использование кучи. После отладки эти фичи отключаются дабы не съедать ресурсы. Быстродействие быстрее чем стандартные функции IAR и уж тем более быстрее чем TSLF (с другими не измерялся). Менеджер делает примитивную фрагментацию в виде слияния свободных блоков в один.

Естественно перед написанием просмотрел много всяких менеджеров вот что могу сказать про TSLF, для таких систем где памяти десятками мегабайт измеряется и очень сложные ОС работают то он может и сыграет кой какую роль, то для контроллеров там где сотни килобайт это никуда не годится. Работает TSLF медленней библиотечной функции, у меня он на таблицу сожрал 3к памяти при куче всегото в 16к куда такое годится! Вобщем не наш это менеджер .

P.S. менеджер потоко не защищенный, используйте синхроницию вашей ос. У меня работет с FreeRTOS и LwIP. Будут вопросы пишите или в аську.

Быстродействие менеджеров - штука не однозназначная. Одно дело выделить блок в пустой куче, другое дело - когда куча многократно выделялась/освобождалась. Я лично сравнивал быстродействие пары задач интенсивно использующих динамическую память. Разницы между BGET и TLSF не увидел.

Естественно, я проверял на пропускной способности стека LwIP c тем или иным менеджером, при динамичном обмене с переменным размером пакета. TLSF пролетает ... еще раз это менеджер для больших серьезных систем там где куча сотни мегабайт, BGET я не пробывал.

Мы лет 6 используем во всех разработках BGET. Когда я его пробовал использовать совместно с LWIP, то он тоже проигрывал встроенному менеджеру. На мой взгляд, подход, реализованный в LWIP очень неплох. Хочешь, используй свой менеджер, не хочешь - вот тебе наш готовый.

в u-boot-е или арм буте есть компактный хорошо проверенный менеджер памяти