Страниц: [1]
  Печать  
Автор Тема: какой должен быть приоритет у watchdog?  (Прочитано 4775 раз)
mike
QOR.Moderator
*****
Offline Offline

Сообщений: 1186


Welcome to Lunatic Asylum.


Просмотр профиля WWW
« : Января 18, 2013, 09:18:59 am »

должен ли watchdog быть самым приоритетным процессом или наоборот?
Записан
Absolut
Full Member
***
Offline Offline

Сообщений: 179


Просмотр профиля
« Ответ #1 : Января 18, 2013, 11:40:30 am »

Главное чтобы он гарантированно получил квант времени в нужный момент (для своих вотчдоговских операций).
Отсюда наверное и надо плясать.
Записан
aluv
Sr. Member
****
Offline Offline

Сообщений: 301


Просмотр профиля
« Ответ #2 : Января 18, 2013, 12:10:55 pm »

Если целевая задача исключает 100% загрузку процессора, то приоритет watchdog можно сделать низким. Для остальных задач приоритет должен быть равен целевым задачам или выше (при условии, что целевые задачи стробируют watchdog).
Записан
vshemm
Sr. Member
****
Offline Offline

Сообщений: 317


Просмотр профиля
« Ответ #3 : Января 18, 2013, 03:39:05 pm »

watchdog вообще не должен быть процессом.
Записан
mike
QOR.Moderator
*****
Offline Offline

Сообщений: 1186


Welcome to Lunatic Asylum.


Просмотр профиля WWW
« Ответ #4 : Января 18, 2013, 04:23:40 pm »

vshemm, это как? встраивать в критическое приложение? а если система из нескольких процессов?
Записан
vshemm
Sr. Member
****
Offline Offline

Сообщений: 317


Просмотр профиля
« Ответ #5 : Января 18, 2013, 04:57:27 pm »

По хорошему, да. По определению, стробирование должно осуществляться из приложения, причем быть синхронным и на
текущем приоритете (в противном случае можно получить false negatives/positives). Если watchdog - отдельный процесс,
добиться этого проблематично. Наименьшим злом, наверное, будет посылка синхронных сообщений, причем watchdog должен
быть самым приоритетным в системе.
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #6 : Января 18, 2013, 08:26:17 pm »

А что вы называете вачдогом? Процесс который кормит аппаратную сторожевую собаку? Его приоритет не имеет большого значения, он должен заблокироваться, если его вовремя не покормили другие процессы критического приложения.
Записан
mike
QOR.Moderator
*****
Offline Offline

Сообщений: 1186


Welcome to Lunatic Asylum.


Просмотр профиля WWW
« Ответ #7 : Января 18, 2013, 09:27:35 pm »

да, процесс который кормит сторожевую собаку Smiley
Записан
vshemm
Sr. Member
****
Offline Offline

Сообщений: 317


Просмотр профиля
« Ответ #8 : Января 18, 2013, 11:40:41 pm »

А кто будет кормить процесс, который кормит сторожевую собаку?
Тут приоритет важен, тут собака и порылась таки Smiley
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #9 : Января 19, 2013, 04:24:14 am »

А почему не кормить сторожевую собаку напрямую? Многие современные аппаратные сторожевые псы весьма гибкие, позволяют задать колличество задач, и таймауты, если какая-то задача не запишет свой байт в порт своевременно, то все и перегрузится. Помнится мне тут уже подымался этот вопрос, и касательно приоритетов.
С софт собакой, если таки ресетить аппаратно по любому чиху нежелательно, я бы рм написал. С конфигурацией, и укажаниями, что делать, если какой процесс перестал писать свой байт в /dev/watchdog.
Записан
PoP
Sr. Member
****
Offline Offline

Сообщений: 336


Просмотр профиля
« Ответ #10 : Января 19, 2013, 04:53:09 pm »

Делать отдельный процесс (поток) только для кормления собаки - вроде как бессмысленно. Проще просто убить её в БИОС-е. Ну, только если в системе живёт единственное приложение, гарантированно не седающее всё время - то поток с минимальным приоритетом. Но потом что-нибудь допишите, сожрёт всё время, и привет.
Под 6-ркой для контроля нескольких процессов можно использовать HAM. Процес, который кормит watchdog, может, таким образом, мониторить только сам HAM.
Под 4-ку нечто аналогичное пришлось писать самому ( кстати, и HAM-а в 6-рке тогда ещё небыло ). Мониторит только зарегистрировавшиеся процессы. По дефолту перезапускается процес, можно попросить убить группуБ перезагрузить систему, только убить процес, просто отметить событие в логах. По ходу работы процес может поменять таймаут, отключить/подключить наблюдение, сменить реакцию на таймаут да и посто отцепиться от ресурса. Как бонус - после регистрации можно спросить первый ли это запуск или перезапуск (и, допустим, не пересоздавать shared memory и т.д. ).
Приоритет в обоих случаях, конечно, должен быть выше, чем у всего контролируемого. Код короткий и тупой, не порождающий новых потоков, проверенный во всех мыслимых и немыслимых вариантах.
« Последнее редактирование: Января 20, 2013, 12:28:28 pm от PoP » Записан
Страниц: [1]
  Печать  
 
Перейти в: