[pernatui 0]

Может быть существуют в открытом коде менеджеры памяти для ARM. Памяти 64к.

 

Заранее спасибо!

[HARMHARM 0]

Уважаемый Zltigo выкладывал здесь.

[pernatui 0]

большое спасибо буду изучать..нашел упоминание об эффективных менеджерах в Micro/OS

на основе этой идеи есть менеджер в Boost. Правда он на c++ и наверное может отожрать много памяти и ресурсов. Хотя при компиляции под IA-32 гораздо эффективнее malloc

[Сергей Борщ 119]

Правда он на c++ и наверное может отожрать много памяти и ресурсов. Хотя при компиляции под IA-32 гораздо эффективнее malloc

Какой-то набор бессмысленных фраз. Что такое malloc как не одна из функций менеджера памяти? С чего бы грамотно написанному С++ приложению жрать лишнюю память и ресурсы? Ну и наконец: в С++ операторы new и delete вызывают все те же malloc() и free().

[pernatui 0]

будьте осторожнее в высказываниях!!! и для начала посмотрите хотя бы на менеджеры памяти о которых я говорю!

[sergeeff 1]

Я уже неоднократно призывал посмотреть форумчан в сторону достаточно нового аллокатора tlsf: http://rtportal.upv.es/rtmalloc/. Написан на С, ставится на любую систему в течение получаса и отличается высоким быстродействием и эффективностью.

[Quasar 18]

Я уже неоднократно призывал посмотреть форумчан в сторону достаточно нового аллокатора tlsf: http://rtportal.upv.es/rtmalloc/. Написан на С, ставится на любую систему в течение получаса и отличается высоким быстродействием и эффективностью.

 

Я посмотрел и даже прилепил к FreeRTOS. Пока впечатление только положительные. :)

[sergeeff 1]

Я посмотрел и даже прилепил к FreeRTOS. Пока впечатление только положительные. :)

 

Вот и я об том же. Испанцы несколько лет разрабатывали этот менеджер и сейчас он вполне работоспособен.

[Rst7 5]

Написан на С, ставится на любую систему в течение получаса

 

Если есть алгоритм, пофиг, на чем писано. Так что это не достоинства, а так, пеар :)

 

и отличается высоким быстродействием и эффективностью.

 

Скажем так, O(1) (а именно такое у него быстродействие) куплено ценой перерасхода ОЗУ. Велик он (перерасход) или нет - зависит от основного кода, как он работает с кучей.

 

По поводу менеджеров. Я где-то рассказывал, какой способ я нынче применяю, повторюсь...

 

Обычные менеджеры требуют довольно длительной блокировки кучи как ресурса - на то время, пока собственно и выполняются действия по занятию/освобождению кусочка. Это часто не позволяет применять прямую работу с кучей в различных реалтаймовых процедурах - вполне возможно, что из-за блокировки кучи как ресурса, будет занято слишком много времени. Стандартный выход - аллоцирование кусочков (обычно фиксированной длинны) для таких задач из заранее заготовленных пулов с соответствующей узкозаточенностью. Пример (хотя и аппаратный) - очереди кусочков в MAC'ах LPC, SAM7, и т.д. Но хотелось бы иметь универсальный алгоритм (и один malloc/free на весь софт).

 

Я сейчас большей универсальности добиваюсь следующим способом:

 

1. Размер аллоцируемых кусочков округляется до некоторой логарифмической сетки (этим уменьшается общее количество различных размеров, но и растет перерасход по памяти).

2. Для каждого размера заранее создается связанный список уже заготовленных кусочков (аллоцированных из большой кучи). Начальное количество в каждой цепочке выбирается исходя из тестовых прогонов софта.

3. Аллоцирование кусочка представляет из себя:

а) табличное округление желаемого размера до выбранной сетки (в большую сторону, конечно),

б) получение начального адреса связанного списка, соответствующего округленному размеру,

в) извлечение из односвязного списка первого элемента.

4. Деаллоцирование - простой возврат кусочка в необходимый список (тоже выполняется в начало списка).

5. В отдельном низкоприоритетном процессе запас кусочков в связанных списках поддерживается на каком-то выбранном уровне (задается по результатам тестовых прогонов). Естественно, это происходит возвратом кусочков из списков в большую кучу (если кусочков слишком много) и занятием новых кусочков и добавлением в список (если кусочков слишком мало).

6. В пункте 3 есть аварийный режим (ежели нужный список пуст) - большая блокировка на занятии кусочка из большой кучи. При правильно выбранных коэффициентах в пункте 5 этот пункт никогда не случается ;)

 

Только пункт 3в (и аналогичный код в возврате кусочка) требует блокировки ресурсов. Причем, т.к. код, выполняемый в состоянии блокировки минимален (не в смысле О(1), а в самом прямом смысле - не более десятка команд процессора), то оказывается вполне возможным производить блокировку не поднятием больших примитивов синхронизации на уровне ОС, а банальным запрещением прерываний.

[AlexandrY 2]

По этой ссылке голый алгоритм хотя и работоспособный.

Это не то что обычно нужно малым embedded системам.

Там и авторы все время подчеркивают для каких сценариев использования делали алгоритм.

Он сделан для мультимедийных приложений где реально применимы статистические модели.

А для малых embedded с 64K на борту это совсем неприменимо, там запросы на память можно на пальцах пересчитать.

Тем более что алгоритм TLSF сразу отжирает около 10K на свой мапинг и реально его процедуры будут медленее выполнятся по сравнению с простейшими списочными менеджерами в пределах 64K.

 

Вообщем IMHO: менеджер малой системы должен главное быть многозадачным, чтоб не мудрить самому с семафорами (в TLSF этого нет), иметь фичу выделения пулов блоков фиксированной длины (в TLSF этого нет) , иметь возможность ожидания освобождения памяти (в TLSF этого нет), иметь диагностические тулсы и логи для идентификации утечек памяти(в TLSF этого нет).

 

 

Я уже неоднократно призывал посмотреть форумчан в сторону достаточно нового аллокатора tlsf: http://rtportal.upv.es/rtmalloc/. Написан на С, ставится на любую систему в течение получаса и отличается высоким быстродействием и эффективностью.

 

 

Браво, вы изобрели велосипед!

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

Но тут еще есть нюансик.

Для таких приложений как Ethernet-а не нужно выделять непрерывные области, там с успехом применяеться DMA по связным спискам.

И моя "идея" пошла лесом.

 

А определять тестовыми прогонами оптимальную сетку нарезки для блоков фиксированной длины это гемор почище чистых malloc-ов.

В конце концов будет либо перерасход памяти либо перерасход нервов. Короче по любому мозги пострадают.

 

Я сейчас большей универсальности добиваюсь следующим способом:

[Rst7 5]

Браво, вы изобрели велосипед!

 

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

 

А определять тестовыми прогонами оптимальную сетку нарезки для блоков фиксированной длины это гемор почище чистых malloc-ов.

 

Сетка задана изначально (у меня обычно применяется шаг 1.5). Начальное количество при инициализации менеджедра - вот это да, это опытным путем. Но совсем не обязательно. На самом деле, даже задание нулевых размеров приведет в начале к тормозам системы (потому что все время будет выполняться "аварийный" режим по пункту 6), пока не устаканится некоторое среднее значение с запасом (определяется порогами в низкоприоритетном процессе).

 

В реальной жизни профилирование весьма несложно. Но зато дает отличные результаты.

 

Но тут еще есть нюансик.

Для таких приложений как Ethernet-а не нужно выделять непрерывные области, там с успехом применяеться DMA по связным спискам.

 

Да, это ньюанс. Но он связан с тем, что DMA уже заточен под список. А часто это еще и полностью своя отдельная область памяти, в которой он (DMA) может разгуляться. Так вот пусть там и гуляет, нефиг туда своими менеджерами лезть :)

[AlexandrY 2]

Мда, это находка, патентовать надо ;)

Эт уже только в операционках под чипы с MMU пулами памяти управляют динамически.

 

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

Что остается? Только своя самописанная часть.

Ну так поставить операционку с менеджером и закрыть тему. Я так всегда рекомендую Keil RTX Kernel. Тупая, быстрая и проблему выравниваний понимает.

 

Есть еще нюансы требующиеся при выделении памяти: она должна в SoC ARM-ах выделяться в большинстве случаев выровненной по границе 4, часто 8 и иногда 16 и больше байт, причина в особенностях DMA и шинной архитектуры. Этого не учитывают менеджеры пришедшие из других архитектур.

 

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

[Rst7 5]

Мда, это находка, патентовать надо Эт уже только в операционках под чипы с MMU пулами памяти управляют динамически.

 

Как то неуместна ирония. Я совсем не претендую на "изобретение" (так, делюсь опытом). Кроме того, мне кажется, я достаточно прозрачно объяснил смысл такого действа - минимизация нахождения в заблокированном состоянии (не в терминах "О(чегото)", а в командах или тактах) и универсальность (одна куча и один интерфейс на всех и вся). А эта универсальность приводит к тому, что чуть ли ни единственным сервисом ОС для межзадачного взаимодействия становится канал (pipe), реализуемый в виде односвязного списка сообщений. Причем, этот канал имеет минимум накладных расходов - ведь менеджер кучи очень быстр.

[sergeeff 1]

Если нет памяти и хочется чего по-проще, есть знаменитый BGET http://www.fourmilab.ch/bget/, который живет с 1972 в миллионах embedded приложений.

[AlexandrY 2]

Я вообще-то без иронии, хотел типа уважительно выразиться.

 

Но кто реализует по такой вашей коротенькой спецификации этот алгоритм?

А выложете, так скажем, опенсорсом?

 

А между тем в местном архиве пяток исходников операционок лежит с готовыми проверенными менеджерами памяти.

И тогда вопрос как всегда упирается в выбор операционки.

 

Как то неуместна ирония. Я совсем не претендую на "изобретение" (так, делюсь опытом). Кроме того, мне кажется, я достаточно прозрачно объяснил смысл такого действа - минимизация нахождения в заблокированном состоянии (не в терминах "О(чегото)", а в командах или тактах) и универсальность (одна куча и один интерфейс на всех и вся). А эта универсальность приводит к тому, что чуть ли ни единственным сервисом ОС для межзадачного взаимодействия становится канал (pipe), реализуемый в виде односвязного списка сообщений. Причем, этот канал имеет минимум накладных расходов - ведь менеджер кучи очень быстр.