как узнать частоту таймера ядра

таймера прерываний? как-то так http://ideone.com/DuEqzt

ух, а попроще вариантов нету?)

$zcat /proc/config.gz |grep HZ
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_RCU_FAST_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
# CONFIG_MACHZ_WDT is not set

Надо узнать один раз для себя или это будет где-то в коде? Зачем?

для себя хочу узнать, и нужно узнать не динамический ли он стоит.

root@n5:~# $zcat /proc/config.gz |grep HZ -bash: /proc/config.gz: No such file or directory

во-первых zgrep HZ /proc/config.gz

CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000

kernel timer interrupt frequency is approx. 4016 Hz or higher

?

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

root@n5:~# zgrep HZ /proc/config.gz

gzip: /proc/config.gz: No such file or directory

должна быть включена поддержка в ядре, оно из реп? может быть конфиг для текущего ядра есть в /boot?

http://rghost.ru/private/57968722/aaf5c056e977474a57d17077a9ab56c2

вот, видимо таки 250 стоит... (

250 как правило используется в серверных ядрах ввиду специфики их работы, для пк это мало.

2cpu x5650, работает с игровыми серверами, таймер надо 1000 поставить и динамический отключить. Возможно ли это без перекомпиляции ядра?

да, там включено NO_HZ, так что особой роли это не играет, проверить частоту работы таймера поможет вышеприведённый код. для игрового сервера 250 тоже мало (хотя это имхо)

можно добавить nohz=off в параметры ядра, например, насчёт частоты не знаю

ещё я бы не поставил oldstable дебиан на сервер, если заботился о его безопасности :3

вобщем только перекомпилировать ядро надо так?

о какой именно безопасности речь?)

ну security-фиксы они обещали выпускать для LTS, но всего не предусмотришь, мне было бы несколько ссыкотно. да и слишком старое по не очень удобно.

можно взять конфиг от используемого сейчас и поправить только частоту, займёт несколько минут времени.

понятно. что посоветуешь на счет частоты, только перекомпиляция ядра поможет?

для начала можно попробовать

nohz=off в параметры ядра

вдруг окажется лучше? :3

кстати тут написано кое-что интересное на эту тему https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt

Лучше врядли будет, оно же прыгало в рамках 250 а надо 1000

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

Старое ядро можно сохранть как-то? вдруг хуже будет)

новое можно поставить рядом, вместо того, чтобы не перетирать старое. или если оно из реп, переустановить (этот вариант может быть проще, поскольку его можно просто поставить на место старого)

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

При этих манипуляциях файлы не полетят которые на сервере?

watch -n 1 cat /proc/interrupts

и прикидываешь, на какое число суммарно увеличиваются счётчики за секунду

http://rghost.ru/57975126 а куда смотреть?

$ ./a.out kernel timer interrupt frequency is approx. 4016 Hz or higherlolwhat? в конфиге 100(сто)

для пк это мало

мало для чего?

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

и как верифицировать, что мало

откуда мне знать?) мои сведения основываются на опыте обращения с веткой 2.6, может что и поменялось, а тест вообще первое, что выдал гугл.

вероятно проявит себя во всяких игрушках, субъективно проблемы с видеодрайвером может ещё что.

тут (kernel.org) всё написано, вроде бы.

cat /proc/interrupts; sleep 10; cat /proc/interrupts

Желательно в этот момент что-то гонять по сети (например, качать большой файл).

Находите CPU* любую колонку, которая значительно увеличилось, ($старое_значение-$новое_значение)/10.

а всё от того, что у современного железа дикий оверхэд по многим параметрам, в результате разницу видно только на всяких нагрузочных тестированиях.

это я читал, там нет вообще в тексте 100|250|300|1000, лол. на десктопе от более высокой частоты тика вижу только просадку производительности, потому давно сижу на 100

у современного железа дикий оверхэд по многим параметрам

ну что это вообще по твоему значит?

http://rghost.ru/57990286 там вообще ничего не понять) ну я в конфиге посмотрел, там стоит 250hz и CONFIG_NO_HZ=y я так понял делает частоту опроса приложением ядра по запросу приложений, мне это надо в «n» в таком случае

на debian не preempt ядро, возможно это болешее влияние имеет

Вобщем надо вот так сделать http://forum.ubuntu.ru/index.php?topic=155154.0

Посоветуйте кто может такое сделать и сколько денег это стоит.

мде, попробуй поставить linux-image-rt, может прокатит

RT реал тайм я так понимаю, если да, то не надо, нагрузки он него бешенные, и так есть много процессов которые порядка 80% ядра выедают

официальный мануал читал?https://www.debian.org/releases/stable/amd64/ch08s06.html.en

<offtop>какая мякотка, буду дебианщиков в это тыкать теперь

Don't be afraid to try compiling the kernel. It's fun and profitable.

</offtop>

не знаю, мне кажется для рабочей станции важнее низкие задержки, нежели производительность, поэтому 1000, fullpreempt и nohzidle, субъективно они обеспечивают наилучшую отзывчивость.

я преследую цель максимально стабилизировать частоту обработки данных игрового сервера cs 1.6, ну и высокая отзычивость так же нужна.

Нужно CONFIG_NO_HZ=y сменить на n, чтобы приложение не контролировало частоту. CONFIG_HZ=250 сменить на 1000 собственно и всё, вопрос еще насколько сильнее будет нагрука на оборудовании после этого...

я между между любыми состояниями этих опций не вижу разницы в отзывчивости. или речь про измеримые задержки в софте?

вот между говернорами ondemand и performance разницу вижу, и бенчами подтверждается. хотя, опять же, может вижу из-за плацебо

а может это из-за смены performance level в блобе nvidia

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

в любом случае dynticks idle лучше оставить, а в перспективе и dynticks full, тогда высокий rate будет использоваться только когда он необходим http://lwn.net/Articles/549580/

preemption важнее в данном случае и несёт больший оверхэд

так что не будет разници если сменить с 250 на 1000?

в dynticks full без taskset же толку нет