NOHZ в ядре

Погуглить за модератора это честь! http://stackoverflow.com/questions/9775042/how-nohz-on-affects-do-timer-in-li...

Да, читал, не обольщайся. Правда по диагонали. Вроде там только про idle.

Я даже не представляю, что искать там в его коде.

может быть константу HZ?

Хаха, нет, HZ задается при загрузке ядра каждый раз и зависит от того на чем запускается ядро (например на эмуляторах это число меньше), Это частота в герцах, с которой системный таймер будет долбить по процессору. Чаще всего на реальной аппаратуре бывает от 100 до 1500 герц. Так же, это число можно выставить при конфигурации ядра. Так вот, NO_HZ позволяет процессору забивать на системный таймер - «а ну его нафиг». :)

А сетевуха разве не должна генерить свои прерывания?

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

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

Скорее всего драйвер ставит по таймеру какой-нибудь тасклет. Таймер не срабатывает -> тасклет в очередь не добавляется. Если это так, тогда по идее переход на delayed workqueue спасёт отца русской демократии. Хотя я не знаю, может они тоже по таймеру срабатывают…

Она генерит когда пришёл пакет например. Как это поможет если надо отсылать пакеты каждые 3 секунды например?

Да, я примерно так же размышляю. Щас изучаю код драйвера, но чую, засяду я за этим.

А, я думал у тебя входящие пакеты не ловятся.
Тогда странно.

Входящие пакеты ловятся по прерыванию от сетевой карты. Как уже выше сказали. Такие прерывания процессор и ядро не игнорят. Игнорят только от системного таймера. Т.е. видимо, процессор спит, а у драйвера что-то завязано на системный таймер.

NOHZ влияет только на idle-режим процессора или же он может забивать на прерывания даже когда сильно занят?

NO_HZ влияет на частоту прихода прерываний от таймера в во время простоя системы. Если случается простой, то таймерные прерывания отключаются. jiffies не продвигаются до определенного момента, потом прибавляются сразу несколько.

Погрепь драйвер на предмет jiffies.

Ну и почти риторический вопрос, как мне выпрямить код этого драйвера? Я даже не представляю, что искать там в его коде.

NAPI используешь?

Скорее всего драйвер ставит по таймеру какой-нибудь тасклет. Таймер не срабатывает

В режиме NO_HZ отключается только sched_tick, остальные таймеры продолжают функционировать, так что не вариант

Ты, вроде, шариш в теме. Не знаешь, как обновляется jiffies, после того, как процессор проснется? Откуда он знает сколько тиков он проспал?

jiffies не обнуляются. Они наоборот увеличиваются. Прибавляется их число, соответствующее тому, сколько времени процессор проспал.

См. функцию tick_do_update_jiffies64(). Известно время последнего обновления last_jiffies_update, известно текущее время now, полученное из clocksource, посчитать разницу в jiffies — элементарная арифметика.

Благодарю.

Так же нашел эту презентацию: http://www.cs.columbia.edu/~nahum/w6998/lectures/timers.ppt
И документ: http://kernel.org/doc/Documentation/timers/highres.txt

Хех, но пока к разгадке не приблизился. Полсекунды куда-то девается и больше, до 700 мс. Код я посмотрел, регистрируется таймер. Т.е. ядро должно проснуться (разбудить процессор) к этому таймеру и отправить пакет. Если бы поломали таймеры, это бы отразилось на всей системе в целом, но зааффектили только этот код.

Еще, я так понял, что с таймерами есть особенность, зарегистрированный ими код исполняется на том же процессоре, где был зарегистрирован таймер. Это связано с процессорным кэшем. Может проц был занят во время срабатывания таймера? Но не 700 мс же?!

Еще, я так понял, что с таймерами есть особенность, зарегистрированный ими код исполняется на том же процессоре, где был зарегистрирован таймер.

Любой hrtimer, созданный без флага HRTIMER_MODE_PINNED, может мигрировать на другой процессор. В случае компиляции с NO_HZ при постановке с простаивающего процессора он всеми силами пытается это сделать.

Это связано с процессорным кэшем. Может проц был занят во время срабатывания таймера? Но не 700 мс же?!

Срабатывание таймера не мгновенно. Таймер — это внешнее прерывания, а в момент истечения времени они могут быть закрыты. Это первое. Второе — к моменту открытия прерываний могут накопиться несколько истекших таймеров, и не факт, что твой окажется первым в очереди на срабатывание. Третье — где, в каком контексте ты ожидаешь ощутить эффект от срабатывания и меришь время? Если в процессе, то прибавь сюда еще длительность wakeup, а также прими во внимание, что в этот момент может исполняться другая задача, и не факт, что менее приоритетная, чем твоя.

Любой hrtimer, созданный без флага HRTIMER_MODE_PINNED, может мигрировать на другой процессор. В случае компиляции с NO_HZ при постановке с простаивающего процессора он всеми силами пытается это сделать.

Спасибо! HRT - это ведь не то же самое, что и обычные таймеры, описанные здесь в 7.4? http://www.makelinux.net/ldd3/

700 мс для 12-ти ядер по 2 ГГц каждое - это много. И неясно почему код работает без NO_HZ, и не работает с ним. Код должен посылать тестовые пакеты в сеть каждые 100 мс. Т.е. при HZ=100, каждые 10 тиков. Профукать полсекунды времени, т.е. более 50 тиков - это много!

Спасибо! HRT - это ведь не то же самое, что и обычные таймеры, описанные здесь в 7.4? http://www.makelinux.net/ldd3/

Разные. Если интересует большая точность срабатывания, то лучше использовать hrtimer

Хех, но пока к разгадке не приблизился. Полсекунды куда-то девается и больше, до 700 мс.

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