Кое-что об устройстве ядра

[Zeus]

У меня такой "мелкий" вопросец по специфической компиляции ядра: нужно получить большую частоту срабатывания системного таймера и я "разгоняю" ядро (точнее оно разгоняет для меня системный таймер).

Итак, имею ядро 2.6.15.1 скачанное с www.kernel.org
В файле kernel/Kconfig.hz после 38й строчки пришлось добавить:
config HZ_5000
bool "5000 HZ"
help
5000 HZ - for realtime application Linux Kernel

config HZ_10000
bool "10000 HZ"
help
10000 HZ - for more realtime application Linux Kernel

После этого:
make menuconfig показал требуемые пункты меню в разделе "Процессор" и всё такое...
Выбрал 10000 HZ.
Сохранил .config, однако компилиться оно не захотело, ругаясь, что не определён SHIFT_HZ
Полез в include/linux/jiffies.h - там куча препроцессорных if'ов, определяющих SHIFT_HZ в зависимости от значения HZ.
Понятно, что для больших значений SHIFT_HZ не определялся.
Добавил.

Всё-равно не компилится:
файл /include/net/inet_timewait_sock.h ругается, что Unsupported: HZ <= 16 or HZ > 4096
Расширил я, так сказать, "суппортет Hz" до нужных мне значений.

Скомпилировалось. Установилось.
Перезагружаюсь - kernel panic. Среди цифирок были такие слова про деление на ноль, calibrate_delay.

Полез смотреть init/calibrate.c.
Там какой-то не совсем понятный код (ну понятно - калибруют там чего-то ), где HZ участвует делителем значений 5000 и 500000.
И видно, что если HZ=10000, то в одном случае (учитывая целочисленное деление) вываливается "деление на ноль".
Пока я переконфигурил для HZ=5000 и сейчас ядро компилится.
Но вопрос встал: что это за значения такие? 5000 и 500000 - почему прямо числами забиты в код?

Ну и напоследок: не слишком я "в лоб" решаю задачу?

Отчёт:
Откомпилировал ядро с HZ=5000. Линух загрузился. Вроде всё работает. Сейчас сижу как-раз под этим ядром.
Тестовый модуль показал частоту срабатывания таймера - 5000 раз в секунду.
Мне, видимо, для моей задачи хватит пока, но железка может 10 кГц.
Так что хотелось бы разобраться с HZ=10000.

[vadiml]

в каком-то из последних ядер (20-е или 21-е) переработали таймер для увеличения кол-ва тиков. Может стоит их посмотреть?

[serzh-z]

переработали таймер для увеличения кол-ва тиков

В 2.6.21 частично реализовали динамические таймеры. Думаю - автору это не подойдет.

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

Что касается ошибки при сборки модулей стека TCP/IP - могу обрадовать тем, что в стеке для ядра 2.6.20 код расчета времени для состояния TIME_WAIT вообще не поддерживает HZ > 4096 тиков.

Что касается ошибки деления на нуль - просто разработчики ядра не ожидали, что кому-то взбредет в голову использовать на современных процессорах подобное значение. Полагаю, что константы 5* необходимы для того, чтобы более наглядно отобразить богомипсы, с учетом того, что пустой цикл может занимать от пяти тактов процесссора (а такие большие числа - по причине того, что в используется нецелочисленая арифметика в целом числе).

[Zeus]

В 2.6.21 частично реализовали динамические таймеры. Думаю - автору это не подойдет.

А это "каг"? Он "на ходу" может изменять частоту или при загрузке машины можно передать параметр ядру? (кстати, если последнее - то странно, что до сих пор такого не было - неудобно каждый раз ядро перекомпилировать).

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

Дикое?
Мне нужно опрашивать тормозное АЦП, у которого предельная частота дискретизации сигнала 10кГц (как видите, 5кГц это для меня пока компромис - собираюсь "разгонять" дальше )
Прерывание по окончании АЦП спасло бы отца русской демократии, но его плата не генерит. Только программный опрос.
Он должен быть регулярным (что-то вроде осциллографа делаю), т.е. - таймер.

Что касается ошибки при сборки модулей стека TCP/IP - могу обрадовать тем, что в стеке для ядра 2.6.20 код расчета времени для состояния TIME_WAIT вообще не поддерживает HZ > 4096 тиков.

Я жутко обрадовался.
В моём ядре, как я упомянул, тоже TCP/IP "ругнулся" при компиляции.
На свой страх и риск попробовал-таки поправить файлик, чтобы скомпилировалось - оно скомпилировалось и работает.
Насчёт устойчивости - не знаю, я только с часик успел на таком ядре поработать, а потом рабочий день закончился.
Завтра буду весь день под ним сидеть.

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

Э-э... а причём тут "современность" процессоров?
Просто - плохой стиль программирования: всобачивать прямо в код число.
Вот и гадай теперь - что это за пятёрки с нулями?

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

Что-то ничего не понял.

[serzh-z]

Что-то ничего не понял.

В ядре нельзя использовать арифметику с плавающей запятой. Потому все вещественные числа (а BogoMIPS выражается вещественным числом) представляются в виде целого. 500000 - это 5000,00. А вот что такое пятерка - ХЗ, даже самому интересно стало, но так и не понял.

В любом случае это число влияет лишь на текстовое представление BogoMIPS и не более того.

А это "каг"? Он "на ходу" может изменять частоту или при загрузке машины можно передать параметр ядру? (кстати, если последнее - то странно, что до сих пор такого не было - неудобно каждый раз ядро перекомпилировать).

При загрузке можно лишь передать значение BogoMIPS (точнее не его, а кол-ко пустых циклов за один тик). Динамические таймеры означают необходимость перепрограммирования таймера после каждого срабатывания. С обычными таймерами ядру приходится при *каждом тике* проверять не пора ли пнуть какой-нибудь из обработчиков на предмет срабатывания. В случае с динамическими таймерами ядро может выставить свой обработчик (прерывания таймера) на определенное время, после срабатывания таймера выставить время срабатывания на следующую временную отметку и так далее. Плюсы - снижается нагрузка на процессор при слишком высоком HZ и пропадает необходимость холостых переключений в обработчик прерывания от таймера. Минусы - сложность реализации. Как я понимаю в новом ядре реализовали *частичную* поддержку дин. таймеров.

[Zeus]

Ладно, с богомипсами всякими потом буду разбираться.
Пока вроде ядро устойчиво работает на 5 кГц таймере: сегодня весь день под ним сидел, глюков не заметил.
Железо, сеть, софт какой нужен был - всё функционирует.
Теперь осталось драйверок накидать и софтинку-отображалку.

[BlackStar]

Для коротких задержек используйте:

void udelay(unsigned long usecs);

Функция определена в </linux/delay.h> и позволяет задержать выполнение на указанное количество микросекунд с использованием цикла.

(с) Роберт Лав, Разработка Ядра Линукс

[Zeus]

Для коротких задержек используйте:

Функция определена в </linux/delay.h> и позволяет задержать выполнение на указанное количество микросекунд с использованием цикла.

(с) Роберт Лав, Разработка Ядра Линукс

Ну драйвер-то может сидеть и задержки генерить-генерить-генерить....
А остальной системе когда работать?

Мне не задержки нужны, а периодичное выполнение опроса железа.

[BlackStar]

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

[Zeus]

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

Ладно, есть у меня процедура в модуле ядра, которая подвязалась вызываться по каждому срабатыванию таймера.
Таймер срабатывает стандартные 250 Гц.
Мне нужно - 5 кГц (в 20 раз больше).
Я значит в каждом вызове этой процедуры гоняю 20 раз цикл с чтением-задержкой (программная задержка - это просто "ничегонеделание" - типа те самые богомипсы).
Как раз где-то к концу 20й итерации цикла придёт следующее прерывание таймера. И опять всё снова.
А когда всему остальному-то работать?
У меня, получается, проц будет 99% времени перелопачивать программные задержки, а вся остальная работа встанет?

[v04bvs]

Тебе нужна Realtime OS, коей линукс по умолчанию не является.

[Zeus]

Тебе нужна Realtime OS, коей линукс по умолчанию не является.

Линукс по-умолчанию является системой с открытыми исходными кодами.
Я их поправил под свои нужды - если время покажет устойчивость такого решения, то почему бы не принять его на вооружение?
В конце концов realtime патчи на линуховое ядро, думао, делают примерно то же самое.

[BlackStar]

В конце концов realtime патчи на линуховое ядро, думао, делают примерно то же самое.

Конечно же нет

А когда всему остальному-то работать?

Это забота планировщика

У меня, получается, проц будет 99% времени перелопачивать программные задержки, а вся остальная работа встанет?

Увеличив значение HZ, которое кстати является платформо-зависимым (100, 500, 1000 для х86), ты увеличил накладные затраты процессора на обработку прерываний таймера. "Это приводит к тому что другим задачам отводится меньше процессорного времени и к периодическому трэшенгу кэша процессора" (с) Роберт Лав.

По поводу задержек, вот пример использования drivers/usb/host/ehci-hcd.c:

Код: Выделить всё

do {
  result = readl (ptr);
  /* … */

  if (result == done) return 0;
  udelay (1);    /* Internally uses loops_per_jiffy */
  usec--;
} while (usec > 0);

И зачем надо так стараться изменить исходники как есть специальные API функции?

[Zeus]

Конечно же нет

А что ж тогда они делают?
Раньше мы работали на пропатченом для realtime ядре 2.18.
Там была возможность подписаться на периодический вызов своей функции с высокой частотой.
И как, по твоему, это было реализовано на аппаратном уровне?

Это забота планировщика

Если он управление получит.
Даже если получит: моя таймерная функция, работающая на уровне ядра, как я понимаю, вытеснена не будет.
Остальные потоки к процессору подключены не будут.

Увеличив значение HZ, которое кстати является платформо-зависимым (100, 500, 1000 для х86) ты увеличил накладные затраты процессора на обработку прерываний таймера. "Это приводит к тому что другим задачам отводится меньше процессорного времени и к периодическому трэшенгу кэша процессора" (с) Роберт Лав.

Поправка: 100, 250, 1000.
А в чём проявляется зависимость от платформы?
На PC можно зарядить таймер больше мегагерца (там опорная частота 1 МГц с хвостом). Главное, чтобы проц успевал обрабатывать.
Насчёт повышенной нагрузки на проц: я осознаю это. Думаю четвёртый пень на 2ГГц уж как-нибудь справится с 5кГц.
Что, впрочем, он подтверждает уже несколько дней: я и сейчас пишу, работая на этом ядре.
Никаких заметных изменений в поведении системы я не вижу.

По поводу задержек, вот пример использования drivers/usb/host/ehci-hcd.c:

Код: Выделить всё

do {
  result = readl (ptr);
  /* … */

  if (result == done) return 0;
  udelay (1);    /* Internally uses loops_per_jiffy */
  usec--;
} while (usec > 0);

Это разовая задержка: ожидание handshake'а от устройства в течении какого-то там количества микросекунд.
Мне же нужно регулярно выполнять свою функцию раз в 100-200 микросекунд (пока остановился на верхнем значении).
Эту задачу задержками не решишь.

И зачем надо так стараться изменить исходники как есть специальные API функции?

Поверь - я не ради праздного любопытства этим занимаюсь: надо по работе, а "специальные API функции" не удовлетворяют требованиям задачи.

[Zeus]

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

Никто ещё не читал её? Как она? "Косяков" много?

P.S. Только анонс не читайте - он явно не от этой книги. Содержание смотрите.

[BlackStar]

Я читал, особых косяков не заметил. Мое мнение: книга является хорошим дополнением к всем известной Роберта Лава. Какие-то темы рассматриваются глубже, какие-то нет.

Вообщем теперь их две (книги по ядру на русском)

[serzh-z]

Мое мнение: книга является хорошим дополнением к всем известной Роберта Лава.

Подписываюсь. Сложилось впечатление в точности такое же (если бы "Азбука" вышла раньше, то "Разработку ядра", наверное, можно было бы назвать дополнением первой).

P.S. ужасное количество неточностей перевода, опечаток в коде и прочих косяков (чего стоит водопроводный термин "вентиль" - вместо более принятого "шлюз", gate)... Хотя, как я понимаю, в оригинале часть из них тоже присутствовала.

[Apocalypse]

Дикое?
Мне нужно опрашивать тормозное АЦП, у которого предельная частота дискретизации сигнала 10кГц (как видите, 5кГц это для меня пока компромис - собираюсь "разгонять" дальше )
Прерывание по окончании АЦП спасло бы отца русской демократии, но его плата не генерит. Только программный опрос.
Он должен быть регулярным (что-то вроде осциллографа делаю), т.е. - таймер.

А не проще ли сделать небольшую платку со, скажем, микроконтроллером от Atmel (исходя из частот можно порекомендовать дешевый ATMega8). Микроконтроллер будет опрашивать Ваш АЦП и по окончании преобразования генерировать прерывание (и выводить слово данных в порт).. Для АВР-микроконтроллеров можно писать программы на С, в любом (по крайней мере, в Debian-based точно есть) линукс-дистрибутиве есть AVR-GCC.

P.S. Тему поднял, конечно, старую, но захотелось и свои пять копеек внести..

[Zeus]

Проще уж тогда поставить плату с таймером, завести от него прерывание и по прерыванию читать АЦП.
Но на будущие проекты я нашёл решение лучше: АЦП с внутренним буфером.
Генерит прерывания при опустошении буфера, при достижении половины, при переполнении буфера - как настроишь.
Может сам переключаться между 32мя каналами.

[Apocalypse]

Проще уж тогда поставить плату с таймером, завести от него прерывание и по прерыванию читать АЦП.
Но на будущие проекты я нашёл решение лучше: АЦП с внутренним буфером.
Генерит прерывания при опустошении буфера, при достижении половины, при переполнении буфера - как настроишь.
Может сам переключаться между 32мя каналами.

Хорошее решение
[OFFTOPIC]
Если не секрет - сколько такая радость (плата АЦП) стоит?
[OFFTOPIC]

[Zeus]

Где-то около $350 в Ниеншанце.

[RasenHerz]

я могу помочь в написании статьи по ядру! уже давно увлекаюсь всем этим делом =)... хотелось бы попрактиковаться в написании статеек
а так вопросы по ядру можно задавать и мне...

[VoidExp]

Ядерным физиком не являюсь, но от себя добавлю карту кернела, может быть поможет при всевозможных объяснениях

[IMB]

Приветствую!
Имеется задача написать драйвер ядра для CMOS-матрицы с кофигурированием по I2C.
Насколько я разобрался есть два похода к решению данного вороса:
- псевдофайловые системы
взаимодействие осуществляется через чтение/запись в фалы находящиеся в /proc или /sys
- символьное устройство
взаимодействие осуществляется через ioctl(/dev)
Хотелось бы услышать мнение опытных людей о том, как лучше реализовать поставленную задачу.
Я уже нашел некий объем информации по данному вопросу, (LDD, несколько статей на opennet.ru и www.ibm.com), но если бы привели ссылки на материалы по данному вопросу, или просто названия книг, статей, я бы тоже был благодарен.
Спасибо.

[Stauffenberg]

Доку для начинающих кернел девелоперов

*** Cтатьи ***

Page Cache, the Affair Between Memory and Files [en]
A Simple Introduction to Device Drivers under Linux [en]
Введение в написание модулей ядра Linux [ru]
Анатомия загружаемых модулей ядра Linux [ru]
Модули ядра [ru]
Написание драйверов под Linux: рекомендации, типичные ошибки и ловушки [ru]
Anatomy of the Linux kernel [en]
Kernel command using Linux system calls [en]
Anatomy of the Linux networking stack [en]
Access the Linux kernel using the /proc filesystem [en]
The Kernel Boot Process [en]
Немного криптографии [ru]
Fuse: Virtual filesystems [en]
Conceptual Architecture of the Linux Kernel [en]

*** Книги ***

The Linux Kernel Module Programming Guide [en]
Энциклопедия разработчика модулей ядра Linux [ru]
Linux-Treiber entwickeln [de]
Разработка модулей ядра ОС Linux [ru]

Professional Linux Kernel Architecture [en]
Understanding the Linux Kernel [en]
Essential Linux Device Drivers [en]
(Essential Linux Device Drivers на гугле [en])


*** еще ***

http://kernel.org/ -- The primary repository of Linux kernel sources [en]
http://kernelnewbies.org -- a community of Linux kernel developers [en]
http://linuxkernel.ru -- сообщество Linux kernel энтузиастов [ru]
http://kernelplanet.org/ -- На сайте собраны воедино публикации из различных блогов Linux разработчиков [en]
http://lkml.org/ -- the Linux Kernel Mailing List Archive [en]
http://kerneltrap.org/
http://lwn.net/Kernel/ -- LWN.net's coverage of Linux kernel development is detailed, technical, and timely [en]
http://makelinux.net/ -- Много интересноо материала по ядру Linux и системе GNU/Linux вообще [en]
http://debianlinux.net/linux.html -- Linux Kernel Project (Debian) [en]

Kernel routines (Non standard)
linux/Documentation/i386/boot.txt -- Boot process

диаграмма ядра Linux
"карта" ядра Linux

[Stauffenberg]

а так вопросы по ядру можно задавать и мне...

I need info about "serio" subsystem.

...ну и не только инфа, но и описание интерфейсов.

Что-то типа этого: linux/drivers/input/serio/i8042.c <---> linux/drivers/input/keyboard/atkbd.c

з.ы. уже разобрался

[Nothing1sZever]

Если за чашкой кофе, я бы начинал с этого

Доку для начинающих кернел девелоперов

*** Cтатьи ***


Anatomy of the Linux kernel [en]

или на русском http://www.ibm.com/developerworks/ru/library/l-linux-kernel/

Остальное по мере надобности.

[Stauffenberg]

A series of posts about the linux kernel and its insides (Online)

Я сам не читал, за feedback буду благодарен.

[Stauffenberg]

Национальный Отрытый Университет ИНТУИТ

Курс: Внутреннее устройство ядра Linux

Лекция 1: Введение
Лекция 2: VFS. Часть 1
Лекция 3: VFS. Часть 2
Лекция 4: VFS. Часть 3
Лекция 5: Сетевая подсистема. Часть 1
Лекция 6: Сетевая подсистема. Часть 2
Лекция 7: Сетевая подсистема. Часть 3
Лекция 8: Сетевая подсистема. Часть 4
Лекция 9: Планировщик
Лекция 10: Page Cache

Возможно кто-то еще не видел. Достаточно занимательно.
Микрофон только у лектора, вопросы "из зала", к сожаленью, не слышно.