[devel] CONFIG_HZ in kernels

[devel] CONFIG_HZ in kernels

[Epiphanov Sergei]

Потребовалось тут ядро с максимально возможным значением HZ, но из имеющихся 
только wks-smp было собрано с CONFIG_HZ_1000, остальные с только с 
CONFIG_HZ_250. Скажите, какая "политика партии" в этом отношении? Придётся 
ли самому собирать под себя с другим HZ или это будет изначально? Меня 
интересуют ядра серии pae-smp.

-- 
С уважением, Епифанов Сергей

Re: [devel] CONFIG_HZ in kernels

[Michael Shigorin]

On Fri, Mar 02, 2007 at 12:26:01PM +0300, Epiphanov Sergei wrote:
> Потребовалось тут ядро с максимально возможным значением HZ, но
> из имеющихся только wks-smp было собрано с CONFIG_HZ_1000,
> остальные с только с CONFIG_HZ_250. Скажите, какая "политика
> партии" в этом отношении?

Разумная, потому что задранное тормозит жутко.

> Придётся ли самому собирать под себя с другим HZ или это будет
> изначально? Меня интересуют ядра серии pae-smp.

Если зачем-то угораздило выше 1000 -- очевидно, собирать.
Регулируемый через /proc HZ вроде нигде не собран.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] CONFIG_HZ in kernels

[Epiphanov Sergei]

В сообщении от Friday 02 March 2007 18:19 Michael Shigorin написал(a):
> On Fri, Mar 02, 2007 at 12:26:01PM +0300, Epiphanov Sergei wrote:
> > Потребовалось тут ядро с максимально возможным значением HZ, но
> > из имеющихся только wks-smp было собрано с CONFIG_HZ_1000,
> > остальные с только с CONFIG_HZ_250. Скажите, какая "политика
> > партии" в этом отношении?
>
> Разумная, потому что задранное тормозит жутко.

Странно, на wks-smp я чего-то тормозов не наблюдаю. Хотя я могу и не в том 
направлении смотреть. Я сейчас всё свою программу тестирую. Если взять ядро 
pae-smp с CONFIG_HZ_250, то программа дёргается, заметны паузы до 100-200 мс 
(а на больших промежутках времени всё нивелируется), а ядро wks-smp с 
CONFIG_HZ_1000 - всё стабильно держится.

Машина: 2 х Xeon 3,2Гц с включённым HT, материнка Intel (не помню 
маркировки), памяти 1Гбайт. Кроме моей программы параллельно работает только 
sshd, udevd, hal. Все остальные сервисы выключены.

> > Придётся ли самому собирать под себя с другим HZ или это будет
> > изначально? Меня интересуют ядра серии pae-smp.
>
> Если зачем-то угораздило выше 1000 -- очевидно, собирать.
> Регулируемый через /proc HZ вроде нигде не собран.

Я имел в виду вместо параметра CONFIG_HZ_250 включать параметр 
CONFIG_HZ_1000. Скажите, а есть ли штатная возможность поднять HZ выше 1000? 
Или придётся патчить ядро? В документации встретил только про 100, 250 и 
1000.

-- 
С уважением, Епифанов Сергей

Re: [devel] CONFIG_HZ in kernels

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]

On Fri, Mar 02, 2007 at 06:46:09PM +0300, Epiphanov Sergei wrote:
> В сообщении от Friday 02 March 2007 18:19 Michael Shigorin написал(a):
> > On Fri, Mar 02, 2007 at 12:26:01PM +0300, Epiphanov Sergei wrote:
> > > Потребовалось тут ядро с максимально возможным значением HZ, но
> > > из имеющихся только wks-smp было собрано с CONFIG_HZ_1000,
> > > остальные с только с CONFIG_HZ_250. Скажите, какая "политика
> > > партии" в этом отношении?
> >
> > Разумная, потому что задранное тормозит жутко.
> 
> Странно, на wks-smp я чего-то тормозов не наблюдаю. Хотя я могу и не в том 
> направлении смотреть. Я сейчас всё свою программу тестирую. Если взять ядро 
> pae-smp с CONFIG_HZ_250, то программа дёргается, заметны паузы до 100-200 мс 
> (а на больших промежутках времени всё нивелируется), а ядро wks-smp с 
> CONFIG_HZ_1000 - всё стабильно держится.

В wks, помимо CONFIG_HZ_1000, ещё и staircase scheduler из патчей -ck.
Имеет смысл попробовать пересобрать локально std с HZ=1000 и сравнить
поведение - возможно, дело даже не совсем в HZ; staircase scheduler
действительно может вести себя лучше на некоторых задачах.

> Машина: 2 х Xeon 3,2Гц с включённым HT, материнка Intel (не помню 
> маркировки), памяти 1Гбайт. Кроме моей программы параллельно работает только 
> sshd, udevd, hal. Все остальные сервисы выключены.

На этом CONFIG_HZ_1000 вряд ли будет тормозить :)

Неприятности от задранного HZ появляются на более старом железе (где к
тому же ещё и таймер старый, и XT-PIC вместо IO-APIC, что тоже не
прибавляет скорости).

> > Если зачем-то угораздило выше 1000 -- очевидно, собирать.
> > Регулируемый через /proc HZ вроде нигде не собран.

Это, насколько я помню, тормозит ещё больше HZ=1000, поскольку многие
выражения, связанные с задержками, перестают быть константными и
начинают вместо этого вычисляться в runtime.

> Я имел в виду вместо параметра CONFIG_HZ_250 включать параметр 
> CONFIG_HZ_1000. Скажите, а есть ли штатная возможность поднять HZ выше 1000? 
> Или придётся патчить ядро? В документации встретил только про 100, 250 и 
> 1000.

Пока только патчить.  В 2.6.20 засунули ещё вариант 300.  А в 2.6.21
пропихнули-таки dynamic tick.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] CONFIG_HZ in kernels

[Michael Shigorin]

On Fri, Mar 02, 2007 at 06:46:09PM +0300, Epiphanov Sergei wrote:
> > > Потребовалось тут ядро с максимально возможным значением
> > > HZ, но из имеющихся только wks-smp было собрано с
> > > CONFIG_HZ_1000, остальные с только с CONFIG_HZ_250.
> > > Скажите, какая "политика партии" в этом отношении?
> > Разумная, потому что задранное тормозит жутко.
> Странно, на wks-smp я чего-то тормозов не наблюдаю. Хотя я могу
> и не в том направлении смотреть.

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

> > Если зачем-то угораздило выше 1000 -- очевидно, собирать.
> > Регулируемый через /proc HZ вроде нигде не собран.
> Я имел в виду вместо параметра CONFIG_HZ_250 включать параметр
> CONFIG_HZ_1000. Скажите, а есть ли штатная возможность поднять
> HZ выше 1000?  Или придётся патчить ядро? В документации
> встретил только про 100, 250 и 1000.

Мы патчили, чтобы опустить до ста...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] CONFIG_HZ in kernels

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

Hi Sergey!

Friday 02, at 09:01:02 PM you wrote:

<skip>
> > Я имел в виду вместо параметра CONFIG_HZ_250 включать параметр 
> > CONFIG_HZ_1000. Скажите, а есть ли штатная возможность поднять HZ выше 1000? 
> > Или придётся патчить ядро? В документации встретил только про 100, 250 и 
> > 1000.
> 
> Пока только патчить.  В 2.6.20 засунули ещё вариант 300.  А в 2.6.21
> пропихнули-таки dynamic tick.
тока что-то глючит 2.6.20 пока нипадеццки. Так что лучше собрать 2.6.18 +
rt патчи из http://people.redhat.com/mingo/realtime-preempt/

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] CONFIG_HZ in kernels

[Epiphanov Sergei]

В сообщении от Friday 02 March 2007 21:49 Michael Shigorin написал(a):
> On Fri, Mar 02, 2007 at 06:46:09PM +0300, Epiphanov Sergei wrote:
> > > > Потребовалось тут ядро с максимально возможным значением
> > > > HZ, но из имеющихся только wks-smp было собрано с
> > > > CONFIG_HZ_1000, остальные с только с CONFIG_HZ_250.
> > > > Скажите, какая "политика партии" в этом отношении?
> > >
> > > Разумная, потому что задранное тормозит жутко.
> >
> > Странно, на wks-smp я чего-то тормозов не наблюдаю. Хотя я могу
> > и не в том направлении смотреть.
>
> Вылазило на специфическом сервере при нагрузочном тестировании
> (под несколько тысяч соединений).

Да, явно не моя задача...

> > > Если зачем-то угораздило выше 1000 -- очевидно, собирать.
> > > Регулируемый через /proc HZ вроде нигде не собран.
> >
> > Я имел в виду вместо параметра CONFIG_HZ_250 включать параметр
> > CONFIG_HZ_1000. Скажите, а есть ли штатная возможность поднять
> > HZ выше 1000?  Или придётся патчить ядро? В документации
> > встретил только про 100, 250 и 1000.
>
> Мы патчили, чтобы опустить до ста...

О как! Тогда всё ясно.

-- 
С уважением, Епифанов Сергей

Re: [devel] CONFIG_HZ in kernels

[Epiphanov Sergei]

В сообщении от Friday 02 March 2007 21:01 Sergey Vlasov написал(a):
> On Fri, Mar 02, 2007 at 06:46:09PM +0300, Epiphanov Sergei wrote:
> > В сообщении от Friday 02 March 2007 18:19 Michael Shigorin написал(a):
> > > On Fri, Mar 02, 2007 at 12:26:01PM +0300, Epiphanov Sergei wrote:
> > > > Потребовалось тут ядро с максимально возможным значением HZ, но
> > > > из имеющихся только wks-smp было собрано с CONFIG_HZ_1000,
> > > > остальные с только с CONFIG_HZ_250. Скажите, какая "политика
> > > > партии" в этом отношении?
> > >
> > > Разумная, потому что задранное тормозит жутко.
> >
> > Странно, на wks-smp я чего-то тормозов не наблюдаю. Хотя я могу и не в
> > том направлении смотреть. Я сейчас всё свою программу тестирую. Если
> > взять ядро pae-smp с CONFIG_HZ_250, то программа дёргается, заметны
> > паузы до 100-200 мс (а на больших промежутках времени всё нивелируется),
> > а ядро wks-smp с CONFIG_HZ_1000 - всё стабильно держится.
>
> В wks, помимо CONFIG_HZ_1000, ещё и staircase scheduler из патчей -ck.
> Имеет смысл попробовать пересобрать локально std с HZ=1000 и сравнить
> поведение - возможно, дело даже не совсем в HZ; staircase scheduler
> действительно может вести себя лучше на некоторых задачах.

Спасибо, понял, что надо почитать.

> > Машина: 2 х Xeon 3,2Гц с включённым HT, материнка Intel (не помню
> > маркировки), памяти 1Гбайт. Кроме моей программы параллельно работает
> > только sshd, udevd, hal. Все остальные сервисы выключены.
>
> На этом CONFIG_HZ_1000 вряд ли будет тормозить :)

Так pae-smp-2.6.18-alt3 на этом жутко дёргается. Раз в 5-10 секунд.

> Неприятности от задранного HZ появляются на более старом железе (где к
> тому же ещё и таймер старый, и XT-PIC вместо IO-APIC, что тоже не
> прибавляет скорости).

Мне это не грозит :)

> > Я имел в виду вместо параметра CONFIG_HZ_250 включать параметр
> > CONFIG_HZ_1000. Скажите, а есть ли штатная возможность поднять HZ выше
> > 1000? Или придётся патчить ядро? В документации встретил только про 100,
> > 250 и 1000.
>
> Пока только патчить.  В 2.6.20 засунули ещё вариант 300.  А в 2.6.21
> пропихнули-таки dynamic tick.

Понял, спасибо.

-- 
С уважением, Епифанов Сергей