MMU - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: MMU
Ivan,

You wrote to Sergey Sobolev:

 >>  NS> При сбое трудно нагадить другому процессу.
 >> С одной стороны, оно, конечно, может быть, но с другой - при
 >> безвременной кончине куска embedded устройства утешение от наличия
 >> оставшихся кусков может быть не большим. ) Hапример, руль отказал,
 >> но колёса ещё крутятся.. ;)
 IM> А если руль отказал, но машина смогла безопасно "сложиться"? Или
 IM> хотя-бы самомтоятельно вызвать похоронную бригаду? =>;->

Зачем так трагично? Реально у "крутых" машин при срабатывании аирбага
автоматически вызывается скорая помощь.


Andrey


Re: MMU
Andrey Arnold пишет:
Quoted text here. Click to load it
Я образно =) Имелось в виду, что при отказе части устройства,
программном или аппаратном, было бы желательно (в порядке уменьшения
последствий):
а) восстановить работу, например, перезапустив программный компонент
б) продолжить работу без отказавшего компонента, если возможно
в) остановить работу устройства с минимальными последствиями для объекта
управления (если мы управляем чем-то силовым, желательно это что-то
выключить/припарковать)
г) собрать какой-нибудь некролог (как минимум - название отказавшего
компонента, как максимум - подобие юниксовой корки).

В этих задачах MMU как минимум не мешает =)

MMU
Привет, Sergey !


 17 Feb 07 , 13:29  Sergey Sobolev писал к All:

SS> Подскажите, плз, для чем полезен MMU?

SS> Какие плюсы я упустил?

При сбое трудно нагадить другому процессу.
ps: Hикогда не отлаживал всяческие утечки или записи по невалидному указателю?
без ММУ - это та еще камасутра.

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... Язык мой - враг мой; сдерживать трудно, засунуть некуда, а отрезать больно.

Re: MMU
Пpивет, Nickita!


 SS>> Подскажите, плз, для чем полезен MMU?
 SS>> Какие плюсы я упустил?
 NS> При сбое трудно нагадить другому процессу.

С одной стороны, оно, конечно, может быть, но с другой - при безвременной
кончине куска embedded устройства утешение от наличия оставшихся кусков может
быть не большим. ) Hапример, руль отказал, но колёса ещё крутятся.. ;)

 NS> ps: Hикогда не отлаживал всяческие утечки или записи по
 NS> невалидному указателю? без ММУ - это та еще камасутра.

Хорошая идея, спасибо.


Sergey

Re: MMU
Thu Feb 22 2007 23:07, Sergey Sobolev wrote to Nickita A Startcev:

 SS>>> Подскажите, плз, для чем полезен MMU?
 SS>>> Какие плюсы я упустил?
 NS>> При сбое трудно нагадить другому процессу.

 SS> С одной стороны, оно, конечно, может быть, но с другой - при безвременной
 SS> кончине куска embedded устройства утешение от наличия оставшихся кусков
 SS> может быть не большим. ) Hапример, руль отказал, но колёса ещё крутятся..
 SS> ;)

Именно.

 NS>> ps: Hикогда не отлаживал всяческие утечки или записи по
 NS>> невалидному указателю? без ММУ - это та еще камасутра.

 SS> Хорошая идея, спасибо.

Использование динамической памяти в более-менее ответственных системах
надо запрещать на...

MISRA C Rule 20.4 (required): Dynamic heap memory allocation
shall not be used.

[Unspecified 19; Undefined 91, 92; Implementation 69; Koenig 32]
This precludes the use of the functions calloc, malloc, realloc and free.
There is a whole range of unspecified, undefined and implementation-defined
behaviour associated with dynamic memory allocation, as well as a number
of other potential pitfalls. Dynamic heap memory allocation may lead
to memory leaks, data inconsistency, memory exhaustion, non-deterministic
behaviour. Note that some implementations may use dynamic heap memory
allocation to implement other functions (for example functions in the
library string.h). If this is the case then these functions shall also
be avoided.

"Liberalism is a mental disorder"


Re: MMU
Hello, Yuriy!
You wrote to Sergey Sobolev on Fri, 23 Feb 2007 00:52:41 +0300:
 YK> Использование динамической памяти в более-менее ответственных системах
 YK> надо запрещать на...

 YK> MISRA C Rule 20.4 (required): Dynamic heap memory allocation
 YK> shall not be used.

 YK> [Unspecified 19; Undefined 91, 92; Implementation 69; Koenig 32]
 YK> This precludes the use of the functions calloc, malloc, realloc and
 YK> free. There is a whole range of unspecified, undefined and
 YK> implementation-defined behaviour associated with dynamic memory
 YK> allocation, as well as a number of other potential pitfalls. Dynamic
 YK> heap memory allocation may lead to memory leaks, data inconsistency,
 YK> memory exhaustion, non-deterministic behaviour. Note that some
 YK> implementations may use dynamic heap memory allocation to implement
 YK> other functions (for example functions in the library string.h). If
 YK> this is the case then these functions shall also be avoided.

Разумное зерно есть, но написано через чур параноидально. С таким подходом
нельзя вообще никакие средства языка С и тем более ОС использовать, т.к.
чревато "...unspecified, undefined and implementation-defined behaviour..."
и "...a number of other potential pitfalls".

На самом деле есть достаточно четкая теория (если можно так сказать :)
использования и менеджмента динамической памяти. При выполнении ряда условий
ни утечки, ни фрагментация не будут иметь место. Одно из ключевых условий
использование объема динамической памяти не более определенного объема (в %
от доступного) и выделение блоков кратного объема на один запрос (с
ограничением максимально допустимого размера блока). Для пущей уверенности
malloc/free должны быть самописные (т.е. использовать известные алгоритмы).

Однако, действительно, там где это можно не использовать - использовать не
нужно. Но если динамическая память даст какие-то выигрыши - использовать ее
можно, возможно система получится в целом более прямая.

WBR,
        AVB



Re: MMU


Quoted text here. Click to load it

    Есть ещё одно соображение. В эхотаге разнообразие структур данных
строго ограничено. Можно предвыделить несколько пулов блоков нужных
размеров и выделять из них.

--
With best regards
Alexander Derazhne




Re: MMU
Fri Feb 23 2007 10:30, Alexey V Bugrov wrote to Yuriy K:

 YK>> Использование динамической памяти в более-менее ответственных системах
 YK>> надо запрещать на...

 YK>> MISRA C Rule 20.4 (required): Dynamic heap memory allocation
 YK>> shall not be used.

 YK>> [Unspecified 19; Undefined 91, 92; Implementation 69; Koenig 32]
 YK>> This precludes the use of the functions calloc, malloc, realloc and
 YK>> free. There is a whole range of unspecified, undefined and
 YK>> implementation-defined behaviour associated with dynamic memory
 YK>> allocation, as well as a number of other potential pitfalls. Dynamic
 YK>> heap memory allocation may lead to memory leaks, data inconsistency,
 YK>> memory exhaustion, non-deterministic behaviour. Note that some
 YK>> implementations may use dynamic heap memory allocation to implement
 YK>> other functions (for example functions in the library string.h). If
 YK>> this is the case then these functions shall also be avoided.

 AVB> Разумное зерно есть, но написано через чур параноидально. С таким
 AVB> подходом  нельзя вообще никакие средства языка С и тем более ОС
 AVB> использовать, т.к.  чревато "...unspecified, undefined and
 AVB> implementation-defined behaviour..."
 AVB> и "...a number of other potential pitfalls".

MISRA C как раз и рассчитана на параноиков. BTW прогнав один из проектов
через IAR MISRA checker, нашел пару-тройку скользких моментов.

Хотя надо признать, что выполнять все "required" правила нереально.

 AVB> Hа самом деле есть достаточно четкая теория (если можно так сказать :)
 AVB> использования и менеджмента динамической памяти. При выполнении ряда
 AVB> условий  ни утечки, ни фрагментация не будут иметь место. Одно из
 AVB> ключевых условий  использование объема динамической памяти не более
 AVB> определенного объема (в %  от доступного) и выделение блоков кратного
 AVB> объема на один запрос (с  ограничением максимально допустимого размера
 AVB> блока). Для пущей уверенности  malloc/free должны быть самописные (т.е.
 AVB> использовать известные алгоритмы).

То есть написать свой менеджер памяти, без неопределенного поведения.
Собственно о чем и речь.

"Liberalism is a mental disorder"


Re: MMU

 SS>>>> Подскажите, плз, для чем полезен MMU?
 SS>>>> Какие плюсы я упустил?
 NS>>> При сбое трудно нагадить другому процессу.

 SS>> С одной стороны, оно, конечно, может быть, но с другой - при
 SS>> безвременной  кончине куска embedded устройства утешение от наличия
 SS>> оставшихся кусков  может быть не большим. ) Hапример, руль отказал, но
 SS>> колёса ещё крутятся..  ;)

 YK> Именно.

 NS>>> ps: Hикогда не отлаживал всяческие утечки или записи по
 NS>>> невалидному указателю? без ММУ - это та еще камасутра.

 SS>> Хорошая идея, спасибо.

 YK> Использование динамической памяти в более-менее ответственных системах
 YK> надо запрещать на...

 YK> MISRA C Rule 20.4 (required): Dynamic heap memory allocation
 YK> shall not be used.

 YK> [Unspecified 19; Undefined 91, 92; Implementation 69; Koenig 32]
 YK> This precludes the use of the functions calloc, malloc, realloc and free.
 YK> There is a whole range of unspecified, undefined and
 YK> implementation-defined  behaviour associated with dynamic memory
 YK> allocation, as well as a number
 YK> of other potential pitfalls. Dynamic heap memory allocation may lead
 YK> to memory leaks, data inconsistency, memory exhaustion, non-deterministic
 YK> behaviour. Note that some implementations may use dynamic heap memory
 YK> allocation to implement other functions (for example functions in the
 YK> library string.h). If this is the case then these functions shall also
 YK> be avoided.

Рекомендация несколько спорная, так как некоторые алгоритмы (например всеми
любимый TCP/IP) не могут быть реализованы в сколько-нибудь значительном объеме
без использования кучи.


Re: MMU
Quoted text here. Click to load it
никакая вменяемая реализация tcp/ip стека (а отнюдь не "алгоритма") не
использует кучу (в
смысле стандартных malloc/realloc/free) а использует фиксированного размера пулы
элементов
фиксированной длины. вообще вменяемые реализации ядер не используют "настоящие"
malloc/free сколь нибудь интенсивно и уж тем более не используют их из clib.

Re: MMU
 >>
 >> Рекомендация несколько спорная, так как некоторые алгоритмы (например
 >> всеми  любимый TCP/IP) не могут быть реализованы в сколько-нибудь
 >> значительном объеме  без использования кучи.
 >>

 AS> никакая вменяемая реализация tcp/ip стека (а отнюдь не "алгоритма") не

??? Какая разница между словами "стек" и "алгоритм" в этом контексте? Чтобы
реализовать протокол TCP/IP нужно совершить некоторые действия с
приходящими/уходящими данными. Последовательность этих (и вообще любых)
действий по определению называется алгоритмом.

 AS> использует кучу (в  смысле стандартных malloc/realloc/free) а использует
 AS> фиксированного размера пулы элементов  фиксированной длины. вообще
 AS> вменяемые реализации ядер не используют "настоящие"  malloc/free сколь
 AS> нибудь интенсивно и уж тем более не используют их из clib.

Куча она всегда куча. :-) То есть некоторый массив памяти с определенными на
нем (минимально) операциями "получить" и "отдать" кусок памяти. А реализация
это дело глубоко десятое. Все равно это куча. Да, бывают "более
реалтаймовские" и "менее реалтаймовские" реализации. Бывают реализации с
дополнительными операциями типа объединения фрагментированных кусков и т.д. Но
все это никак не отменяет того факта, что некоторые алгоритмы полноценно
реализуются только с использованием кучи.

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

Возвращаясь же к исходному вопросу о полезности MMU для встроенных систем
можно сказать, что:

1. Деление на встроенные и невстроенные системы достаточно условное и
определяется в основном количеством допущений, которые может себе позволить
разработчик. Если производители ОС и софта для офиса имеют возможность в любой
момент нажать сброс и перезагрузиться, то производители софта для
пилотирования Боинга такой роскоши позволить себе не могут.

2. Если задача требует кучи, то легче и надежнее (хотя и более трудоемко и
менее переносимо) реализовывать управление памятью (и кучу как частный случай)
если есть хардварная поддержка этого управления в виде MMU.


Re: MMU
Quoted text here. Click to load it

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

ну то есть что такое алгоритм ты представляешь, но не знаешь

Quoted text here. Click to load it

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

короче что такое динамическое выделение памяти ты тоже не в курсе.

Quoted text here. Click to load it

куча никаким образом не предполагает и не требует мму. болнн того - мму никоим
образом не
помогает куче (в отличии от пулов которым таки помогает).

MMU
Привет Sergey!

22 Feb 07 23:07, Sergey Sobolev писал Nickita A Startcev:

 SS> С одной стороны, оно, конечно, может быть, но с другой - при
 SS> безвременной кончине куска embedded устройства утешение от наличия
 SS> оставшихся кусков может быть не большим. ) Hапример, руль отказал, но
 SS> колёса ещё крутятся.. ;)

    А может быть и большим - например, когда при переполнении пепельницы руль
продолжает действовать. :)

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Синяки рождаются в споре куда чаще, чем истина...

Re: MMU
Ivan,

You wrote to Andrey Arnold:

 >>  >> безвременной кончине куска embedded устройства утешение от
 >>  >> наличия оставшихся кусков может быть не большим. ) Hапример,
 >>  >> руль отказал, но колёса ещё крутятся.. ;)
 >>  IM> А если руль отказал, но машина смогла безопасно "сложиться"?
 >>  IM> Или хотя-бы самомтоятельно вызвать похоронную бригаду? =>;->
 >> Зачем так трагично? Реально у "крутых" машин при срабатывании
 >> аирбага автоматически вызывается скорая помощь.
 IM> Я образно =) Имелось в виду, что при отказе части устройства,
 IM> программном или аппаратном, было бы желательно (в порядке уменьшения
 IM> последствий):
 IM> а) восстановить работу, например, перезапустив программный компонент
 IM> б) продолжить работу без отказавшего компонента, если возможно
 IM> в) остановить работу устройства с минимальными последствиями для
 IM> объекта управления (если мы управляем чем-то силовым, желательно это
 IM> что-то выключить/припарковать) г) собрать какой-нибудь некролог (как
 IM> минимум - название отказавшего компонента, как максимум - подобие
 IM> юниксовой корки).
 IM>
 IM> В этих задачах MMU как минимум не мешает =)

Отработка нештатных ситуаций без многократной практической проверки
мало чего стоят, а проверки эти дорогостоящие во всех отношениях.
Прикинь хотя бы что будет, если вызов той же скорой произойдёт нештатно.
И это самое безобидное последствие... помноженное на парк авто;)
Hу а что будет, если скорая штатно не вызовется, а в морге установят,
что его можно было спасти...


Andrey


Re: MMU
Привет Basil!

26 Feb 07 10:56, Basil Burtakov писал Yuriy K:

 BB> Рекомендация несколько спорная, так как некоторые алгоритмы (например
 BB> всеми любимый TCP/IP) не могут быть реализованы в сколько-нибудь
 BB> значительном объеме без использования кучи.

    Вторая часть утверждения (после "так как") неверна.

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Посетители должны общаться по сети.

MMU
Mon Feb 26 2007 15:02, Alex Mogilnikov wrote to Basil Burtakov:

 AM> Привет Basil!

 AM> 26 Feb 07 10:56, Basil Burtakov писал Yuriy K:

 BB>> Рекомендация несколько спорная, так как некоторые алгоритмы (например
 BB>> всеми любимый TCP/IP) не могут быть реализованы в сколько-нибудь
 BB>> значительном объеме без использования кучи.

 AM>     Вторая часть утверждения (после "так как") неверна.

Ну и как предлагается реализовывать, например, сборку фрагментированных
пакетов для некоторого (произвольного) количества одновременно открытых
соединений без использования кучи? С учетом того, что фрагменты в общем виде:

1. разного размера
2. конец приходит раньше начала и поэтому истинный размер пакета не известен
до принятия последнего фрагмента
3. если выделять статически "по максимуму" буфера для каждого пакета, то в
любой физически представимой системе ресурсы очень быстро закончатся
4. ну и так далее


Re: MMU
Привет Basil!

01 Mar 07 10:46, Basil Burtakov писал Alex Mogilnikov:

 BB> Если не секрет, как реализована сборка пакетов на преме из кусков
 BB> разной длины? :-)

    Hикак. Пока еще ни в одном из применений такой функциональности не
потребовалось. Все пакеты укладываются в 1500 байт. У меня даже на персоналке
долгое время (годы) было прописано deny ip from any to any frag...

 BB> Еще вопрос - используется ли шедулер? Или все крутится в одной задаче
 BB> - главном цикле?

    Шедулер используется, для сетевизмов (разбор принятого) создается отдельная
задача. Она в-основном очередь приема разбирает.

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Чем ветеринары кормят своих собак? Белый фосфор. Ваша собака светится!

MMU

 BB>> Если не секрет, как реализована сборка пакетов на преме из кусков
 BB>> разной длины? :-)

 AM>     Hикак. Пока еще ни в одном из применений такой функциональности не
 AM> потребовалось. Все пакеты укладываются в 1500 байт. У меня даже на
 AM> персоналке долгое время (годы) было прописано deny ip from any to any
 AM> frag...

Да, так часто делают. Особенно для применений, которые общаются только внутри
одной езернетовской локалки. Например для кассовых аппаратов, которые никто не
мониторит извне. Однако, как Вы сами понимаете, такое решение никак нельзя
назвать "полноценной реализацией TCP/IP". Скорее это "средство перепихнуться
по UDP в пределах локалки". Или даже "средство для обмена езернетовскими
пакетами в стандарте UDP для того, чтобы через локальные роутеры эти пакеты
все-таки проходили". Однако если такой устройство поставить в нормальную сеть
и попробовать пообщаться с ним издалека, то можно получить отлуп. Например,
связное сетевое оборудование почти всегда имеет технологический канал для
мониторинга и настроек. Если производитель, как часто бывает, находится в
Тайбее :-), а аппаратура стоит на Камчатке, то техсаппорт теоретически можно
осуществлять удаленно. Но если реализация TCP/IP не поддерживает сборку
фрагментированных пакетов, а на пути от Тайбея до Камчатки проложена линия с
максимальным размером пакета меньше, чем в езернете, то несмотря на
исправность всех технических средств связи получить не удасться.

 BB>> Еще вопрос - используется ли шедулер? Или все крутится в одной задаче
 BB>> - главном цикле?

 AM>     Шедулер используется, для сетевизмов (разбор принятого) создается
 AM> отдельная задача. Она в-основном очередь приема разбирает.


Re: MMU
Привет Basil!

01 Mar 07 10:52, Basil Burtakov писал Alex Mogilnikov:

 BB>  А то мне тут в одном месте на полном серьезе втирали,
 BB> что TCP/IP отлично реализуется в однозадачном мониторе. :-)

    Лишь бы своевременно разбиралась очередь принимаемых пакетов. Понятно, что
отдельная задача, которую пробуждает шедулер при появлении чего-то в очереди,
удобнее. Hо не вижу принципиальных препятствий делать это же путем
периодической проверки очереди в каком-то цикле. Отличным я бы это не назвал,
:)  но работать, по идее, должно...

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... в манах то любой ламмер прочитать сможет (c) Andrew Wingorodov

MMU

 BB>>  А то мне тут в одном месте на полном серьезе втирали,
 BB>> что TCP/IP отлично реализуется в однозадачном мониторе. :-)

 AM>     Лишь бы своевременно разбиралась очередь принимаемых пакетов.
 AM> Понятно, что отдельная задача, которую пробуждает шедулер при появлении
 AM> чего-то в очереди, удобнее. Hо не вижу принципиальных препятствий делать
 AM> это же путем периодической проверки очереди в каком-то цикле. Отличным я
 AM> бы это не назвал, :)  но работать, по идее, должно...

Работать будет при многих ограничениях. Например без шедулера невозможно
определить перерыв в связи (невозможно как положено в TCP/IP на каждый пакет
запускать свой таймер и сбрасывать пакет, если не все его части пришли до
истечения таймаута). То есть пакет должен быть принят сразу и целиком. То есть
это опять UDP, а а вовсе не TCP/IP. Ну и общий недостаток главного цикла -
долгая низкоприоритетная задача не отпускает управление, хотя в это время надо
обслужить что-то более высокоприоритетное.


Site Timeline