Интересные настройки ядра

Все о программировании под *nix
Аватара пользователя
Victor Gr.
Неотъемлемая часть форума
Сообщения: 891
Зарегистрирован: 13 авг 2004, 15:39
Откуда: Минск
Контактная информация:

Интересные настройки ядра

Сообщение Victor Gr. »

Привет!

Компилируя ядра, обращаю внимание на самые интересные низкоуровневые настройки :).

Но, вот объяснение для некоторых найти пока не удалось.

Это касается раздела Processor type and features и пункта Timer frequency. По-умолчанию, у меня он был установлен в 250 Гц, что объяснялось разумным компромиссом между производительностью сервера и интерактивностью отклика на SMP and NUMA systems.

Что такое NUMA systems я так и не понял, но переключив этот параметр на 1000 Гц, увидел, что это и есть лучший выбор для настольной системы.

Конечно именно с таким параметром я и скомпилировал ядро, но хочется знать, как это работает. При чём здесь частоты.

Похожие настройки, касающиеся Preemption Model (Preemptible Kernel). Но здесь уже более понятно.

Кажется, при включенном Preemptible Kernel, система становится более отзывчивой, т.к. может блокировать задачи с более низким приоритетом, чтобы исполнить задачи с высоким приоритетом?

Поправьте меня пожалуйста, если я не прав.

Аватара пользователя
Llama
Неотъемлемая часть форума
Сообщения: 9749
Зарегистрирован: 06 фев 2002, 11:40
Откуда: Менск

Сообщение Llama »

Victor Gr.,
1) Variable HZ - то грубо говоря частота переключения процессов в системе. При увеличении уменьшается время отклика но растет оверхед на само переключение
2) Preemptible Kernel - AFAIK это фича которая позволяет динамически понижать приоритет выполнения ядра в пользу некого ресурсоемкого приложения.
Опыт растет прямо пропорционально выведенному из строя оборудованию

Аватара пользователя
Speccyfan
Неотъемлемая часть форума
Сообщения: 540
Зарегистрирован: 18 дек 2004, 15:15
Откуда: Polotsk
Контактная информация:

Сообщение Speccyfan »

Блин взялся тут опять ядро пересобрать, сволько не пытался (на нескольких машинах с разными ядрами) но в дистрибутивах ALT Linux у меня после сборки (из пакета ядро или с kernel.org не важно) Постоянно такой глюк, ядро ругается в сислог на Error, can't read PROC file sistem, хотя реально вроде PROC доступен и виден, в результате klogd тормозит всю систему на 100%, когда его убиваю, все становиться нормально, но это как-то не правильно.
Best Regards, Yury Konovalov aka Speccyfan (2:453/53)
Registered Linux User #379588

Аватара пользователя
Victor Gr.
Неотъемлемая часть форума
Сообщения: 891
Зарегистрирован: 13 авг 2004, 15:39
Откуда: Минск
Контактная информация:

Сообщение Victor Gr. »

Speccyfan, два глупых вопроса: в ядре включена поддержка proc filesystem и ... права доступа в порядке?

Аватара пользователя
Speccyfan
Неотъемлемая часть форума
Сообщения: 540
Зарегистрирован: 18 дек 2004, 15:15
Откуда: Polotsk
Контактная информация:

Сообщение Speccyfan »

в ядре поддержка включена, права впорядке, r-x,r-x,r-x влделец root, группа proc
при запуске klogd в сислог попадает:
Dec 28 13:54:29 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec 28 13:54:29 localhost klogd: klogd startup succeeded
Dec 28 13:54:29 localhost kernel: Inspecting /boot/System.map-2.6.14-speccyfan
Dec 28 13:54:29 localhost kernel: Loaded 21625 symbols from /boot/System.map-2.6.14-speccyfan.
Dec 28 13:54:29 localhost kernel: Symbols match kernel version 2.6.14.
Dec 28 13:54:29 localhost kernel: No module symbols loaded - kernel modules not enabled.
Dec 28 13:54:29 localhost kernel: Cannot read proc file system: 1 - Operation not permitted.
Dec 28 13:54:34 localhost last message repeated 85495 times
тут я уже его просто вырубил
Dec 28 13:54:34 localhost kernel: Kernel logging (proc) stopped.
Dec 28 13:54:34 localhost kernel: Kernel log daemon terminating.
Dec 28 13:54:35 localhost klogd: klogd shutdown succeeded


что вот это такое ?
No module symbols loaded - kernel modules not enabled.

в конфиге у меня так:

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y


по поводу proc:
CONFIG_PROC_FS=y
Best Regards, Yury Konovalov aka Speccyfan (2:453/53)
Registered Linux User #379588

dimm_coder
Интересующийся
Сообщения: 65
Зарегистрирован: 19 авг 2003, 10:56
Откуда: Anwerpen, Belgium / Belarus
Контактная информация:

Сообщение dimm_coder »

Llama писал(а):Victor Gr.,
1) Variable HZ - то грубо говоря частота переключения процессов в системе. При увеличении уменьшается время отклика но растет оверхед на само переключение
Это частота системного таймера, т.е. количество тиков в секунду. Переключение процессов не происходит каждый тик. В общем случае это произойдет если timeslice текущего процесса станет равным 0 (timeslice уменьшается каждый тик).
На данном системном тайемере основана работа "временных"-сервисов ядра. Например, блокировать процесс на заданное количество миллисекунд (что позволяет например работать select() и poll() и т.д.).

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

скажем процесс хочет быть пробужден раз в 25 мс., то посмотри какая может быть разница с разрешением таймера в 1 и 10 мс (1000 и 100 HZ соответственно).

с другой стороны, при большей частоте соответствующая часть кода обработки выполняется более часто - оставляя в принципе меньше времени на выполнение процессов и, например, в том числе влияя на состояние кэша и т.д. В том числе, увеличивая энергопотребление например ноутбуков. На сколько я читал, это скорее вопрос нескольких процентов.

В недавнем времени, был опубликован так называемый "dynamic-tick" патч. Идея, грубо говоря, в том что после некоторого времени простоя система перепрограммирует сис. таймер и он производит прерывания с меньшей частотой. Обратное включение может произойти когда что-то переведет систему из состояние бездействия в активное (появилась задача для выполнение). Это либо прерывания, либо какой-то процесс
был блокирован на определенный промежуток времени и этот момент настал. Система "наверстывает" неучтенные тики с помощью спец. обработчика, так как кол-во (известные jiffies) важно для работы.

Желающие могут поискать информацию в интернет, а также проценты спасенного энергопотребления :)

если требуется более точное разрешение то используется RTC (Real-Time Clock) или подобные.

Llama писал(а):Victor Gr.,
2) Preemptible Kernel - AFAIK это фича которая позволяет динамически понижать приоритет выполнения ядра в пользу некого ресурсоемкого приложения.
нет.

в обшем идею можно проиллюстрировать следующим примером.

процесс блокирован, например в ожидании определенного события.
Он может стать "активным" (TASK_RUNNING) при определенных внешних условиях :

- произошло прерывание и обработчик прерывания "разбудил" данный процесс;

- некоторый в данный момент активный процесс "разбудил" данный процесс;

- процесс был блокирован до определенного момента времени (например он должен делать какую-то работу раз в N милисекунд).

Так вот из-за того или иного события некоторый процесс становится активным. Он готов к выполнению и, допустим, он самый приоритетный процесс в системе. Вот теперь введем понятие "dispatch или scheduling latency" - промежуток времени между тем как некоторый процесс становится активным и моментом когда он действительно начинает выполняться.
Система помечает что есть более приоритетная задача и необходимо провести "вытеснение" текущей в пользу новой.

Если текущий процесс выполняется в user-mode то вытеснение может произойти в данный же момент.

А вот если в kernel-mode то "вытеснение" в данный момент активного процесса в non-preemptible kernel может произойти только в определенных точках:
- если процесс добровольно отдает процессор, блокируясь по той или иной причине;
- если происходит возвращение процесса из kernel mode в user mode.

да отметим, что прерывания прерывают процесс выполняемый в любой точке, если конечно сами прерывания в данный момент разрешены.

В некоторых ядрах добавлялись дополнительный точки "вытеснения".

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

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

например общий код ядра завершающий обработку любого прерывания проверяет установку флага (TIF_NEED_RESCHED) - это значит пользовательский обработчик прерывания разбудил некоторый процесс и он оказался приоритетнее текущего - и если ядро в данный момент preemptible то осуществляется переключение контекстов.

Если нет, то в следующей точке где ядро снова станет preemptible - произойдет переключение.

Как пример,

spin_lock(&some_lock); // ядро становится non-preemptible на данном CPU

...

// происходит прерывание и некоторый высокоприоритетный процесс активизирован, но переключение не может произойти сейчас.

...
spin_unlock(&some_lock); // ядро снова становится preemptible (в упрощенном виде, если ничего более не запрещает) . как результат переключение контекстов.

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

отсюда очевидно, чтобы держать отклик системы на высоком уровне, non-preemptible участки ядра должны быть минимальны, как минимум по времени выполнения.

хм... наверное слишком пространно, но надеюсь я был вполне понятен :)

NUMA?

google в помощь, в общем и по остальным вопросам он бы помог :)

http://lse.sourceforge.net/numa/faq/ind ... _stand_for

Аватара пользователя
Victor Gr.
Неотъемлемая часть форума
Сообщения: 891
Зарегистрирован: 13 авг 2004, 15:39
Откуда: Минск
Контактная информация:

Сообщение Victor Gr. »

Класс!! Спасибо за такое подробное и интересное объяснение!

Ответить