Ответ 1
Сначала давайте понять, что такое набор tickless kernel (NOHZ=On или CONFIG_NO_HZ) и какова мотивация его внедрения в ядро Linux из 2.6.17
Из http://www.lesswatts.org/projects/tickless/index.php,
Традиционно ядро Linux использовало периодический таймер для каждого процессора. Этот таймер сделал множество вещей, таких как учет процессов, балансировку нагрузки планировщика и сохранение событий таймера каждого процессора. Старшая Ядра Linux использовали таймер с частотой 100 Гц (100 событий таймера в секунду или одно событие каждые 10 мс), в то время как новые ядра используют 250 Гц (250 событий в секунду или одно событие каждые 4 мс) или 1000 Гц (1000 событий в секунду или одно событие каждые 1 мс).
Это событие периодического таймера часто называют "таймер". Таймер тик прост в своем дизайне, но имеет существенный недостаток: таймер происходит периодически, независимо от состояния процессора, независимо от того, работает он или занят. Если процессор простаивает, он должен проснуться из энергосберегающего состояния сна каждые 1, 4 или 10 миллисекунд. Эта стоит немного энергии, потребляет время автономной работы в ноутбуках и вызывая ненужное энергопотребление на серверах.
С "безрадовым бездействием" ядро Linux устранило это периодическое таймер, когда процессор находится в режиме ожидания. Это позволяет процессору оставаться в энергосберегающие состояния в течение более длительного периода времени, уменьшая общую потребляемая мощность системы.
Таким образом, снижение энергопотребления было одной из основных причин отсутствия явного ядра. Но, как и в большинстве случаев, производительность поражает снижением энергопотребления. Для настольных компьютеров производительность очень важна, поэтому вы видите, что для большинства из них NOHZ=OFF работает очень хорошо.
В Ingo Molnar собственные слова
Функция безъядерного ядра (CONFIG_NO_HZ) включает таймер "по требованию" прерывания: если таймер не истечет, например, 1,5 секунды когда система переходит в режим ожидания, система будет оставаться бездействующей для 1,5 секунды. Это должно принести более холодные процессоры и экономию энергии: на наших тестовых площадках (x86) мы измерили эффективную скорость IRQ, чтобы перейти от HZ до 1-2 таймерных прерываний в секунду.
Теперь попробуйте ответить на ваши запросы -
Что я не могу понять, так это то, как таймеры hi-res влияют на do_timer?
Если система поддерживает таймеры с высоким разрешением, прерывания таймера могут происходить чаще, чем обычные 10ms для большинства систем. i.e эти таймеры пытаются сделать систему более восприимчивой, используя возможности системы и прерывая прерывания таймера еще быстрее, скажем, каждый 100us. Таким образом, с опцией NOHZ, эти таймеры остывают и, следовательно, нижнее выполнение do_timer
Даже если аппаратное обеспечение hi-res находится в состоянии ожидания, постоянное время больше чем способен выполнять do_timer каждые 10 мс
Да, он способен. Но намерение NOHZ в точности противоположно. Чтобы предотвратить частые прерывания таймера!
Во-вторых, если do_timer не выполняется, когда это необходимо, это означает, что некоторые процессы не получают свой таймшер, когда они в идеале должны быть получить его
Как caf, отмеченный в комментариях, NOHZ не приводит к тому, что процессы получают запланированные реже, потому что они запускаются только тогда, когда CPU неактивен - другими словами, когда никакие процессы не планируются. Только материал учета процесса будет выполнен с задержкой.
Почему do_timer не хватает сроков?
Как уже было сказано, это предполагаемый дизайн NOHZ
Я предлагаю вам перейти в tick-sched.c источники ядра в качестве отправной точки. Найдите CONFIG_NO_HZ и попытайтесь понять новую функциональность, добавленную для функции NOHZ
Вот один тест, выполненный для измерения Влияние ясного неба