watchdog в Linux Опции

[Idle]

Стандартную связку driver(kernel timer) и userspace daemon написал, это просто.
В чем предвижу проблему: сетевые интерфейсы заштормят, живой userspace не отсигналит и идем на ребут. Нас в ребут, а мы крепчаем, да.
Вопросы:
1. Есть вообще какой-то смысл ограничивать watchdog только драйвером, никак не оглядываясь на userspace?
2. Можно вообще реализовать драйвер watchdog, чтобы он "ну уж точно успел дернуть "?

PS Про NAPI в курсе; то что надо на досуге почитывать Лава и LDD, а не тереть с клоунами в оффтопике тоже

[Harbour]

из поста непонятно кто "дергает" - лучше использовать hardware one - если конечно не интересует результат. кто скeазал что драйвер ядра будет всегда выполнятся (ooops/memory corruption/cpu thermal halt) ?

[Idle]

из поста непонятно кто "дергает" - лучше использовать hardware one - если конечно не интересует результат. кто скeазал что драйвер ядра будет всегда выполнятся (ooops/memory corruption/cpu thermal halt) ?

Да, не ясно написал. Watchdog аппаратный, внешняя микросхема. Вопрос о том, как реализовать драйвер, который будет подтверждать что всё ok. Т.е. я боюсь, что драйвер вовремя не получит управление при большой загрузке системы прерываниями от сетевых интерфейсов.

[amw]

Да, не ясно написал. Watchdog аппаратный, внешняя микросхема. Вопрос о том, как реализовать драйвер, который будет подтверждать что всё ok. Т.е. я боюсь, что драйвер вовремя не получит управление при большой загрузке системы прерываниями от сетевых интерфейсов.

В ядре есть реализация драйвером нескольких watchdog. Посмотрите там.

[Idle]

В ядре есть реализация драйвером нескольких watchdog. Посмотрите там.

Так уже посмотрел, написал свой, работает. Проблема в том, что (IMO) при серьезной нагрузке устройство будет перезагружаться не из-за того, что ядро "повисло", а из за того, что процессор занимается обработкой пакетов, и драйвер watchdog не получает управление вовремя.

Сообщение отредактировал Idle - Mar 25 2008, 10:23

[vshemm]

А какой период таймера? Если хотя бы секунд 10 - то, может, все-таки перезагрузиться?
Вообще, при малых периодах таймера его сброс делают не из юзерспейса, а по ядерному таймеру (например, w83877f_wdt.c). В этом случае, даже при большой сетевой загрузке, вотчдог "сбросится", т.к. ядерные таймеры выполняются на уровне softirq, как и основные обработчики сетевых пакетов (причем таймеры даже имеют бОльший приоритет, т.е. будут выполняться в первую очередь).

Сообщение отредактировал vshemm - Mar 25 2008, 12:18

[Idle]

А какой период таймера? Если хотя бы секунд 10 - то, может, все-таки перезагрузиться?

0,5 с

Вообще, при малых периодах таймера его сброс делают не из юзерспейса, а по ядерному таймеру (например, w83877f_wdt.c).

так и сделал, но сейчас еще проверяю флаг, выставляемый userspace-ом, ему даю до 30с - убрать не проблема

Код

static void brandname_wdt_pingtimer(unsigned long data)
{
        if(time_before(jiffies, next_heartbeat))
        {
                /* set timer again */
                timer.expires = jiffies + WDT_INTERVAL;
                add_timer(&timer);
                /* kick watchdog */
                if (flg == 0) {

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

Вот в этом весь мой вопрос. Я не знаю как работает ядро, надо учить матчасть, но спросить не грех. Допустим, что fast обработчик только у таймера, другие обработчики не отключают чужие прерывания.
У меня (и 2.4, и 2.6 ядра) время между срабатыванием таймера и передачей управления моей функции не может при каких-либо условиях оказаться больше 0,5с?

[vshemm]

Ядра 2.6.11+.
Обработка всех softirq (это нечто вроде DPC в WindowsNT) выполняется при разрешенных прерываниях. Инициируется выполнение softirq при выходе из обработчиков аппаратных прерываний (и еще из нескольких мест).
Поэтому, если процессор 100% времени не будет сидеть внутри обработчиков прерываний, он рано или поздно попадет в код "сброса" вотчдога. Как скоро - зависит от обработчиков и интенсивности прерываний.
Т.о., высокая интенсивнось прерываний действительно может привести с перезагрузке по вотчдогу, но система при этом действительно рабочей быть не может. Если требуется в таких случаях просто "переждать" (???), нужно увеличивать таймаут вотчдога (хардварный).
Есть другой случай, когда прерываний мало. Здесь нужно рассчитывать на тик системного таймера. Т.е. выполнение ядерного таймера может задержаться в наихудшем случае на ~1 тик системного таймера от рассчитаного значения (в новых tickless-ядрах немного по-другому ).
Кстати, период таймера обычно делают где-то в 2 раза меньше периода вотчдога - именно по этой причине, чтобы был запас.

С некоторыми оговорками это справедливо и для старших версий ядер 2.4.

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

А у Вас вотчдог умеет генерить прерывания?

[Idle]

А у Вас вотчдог умеет генерить прерывания?

нет, это я на всякий случай

Спасибо за информацию. Ага, значит вызов моей функции вызывается в процессе обработки BH прерывания таймера. BH "накручены" на softirq.

Код

/* timer.c */
void timer_bh(void)
{
        TRACE_EVENT(TRACE_EV_KERNEL_TIMER, NULL);
        update_times();
        run_timer_list();
}

При этом прерывания разрешены. Таким образом, 100Мбит Ethernet заребутит за милую душу.

Выводы такие (я прав?):
1. NAPI драйвер для сетевых устройств.
2. Определенное нахождения в обработчике для всех остальных также.
3. Сумма всех этих времен в худшем случае не должна превышать мой интервал.

система при этом действительно рабочей быть не может

Оборудование сетевое, так что режим "штатный"

Ну в общем, watchdog скорее всего - в топку, дел и так выше крыши.

Спасибо.

[Дон Амброзио]

Делай как я: для каждого потока создавай свой виртуальный Watchdog-таймер

Сообщение отредактировал Дон Амброзио - Mar 27 2008, 13:56