Ядро Linux реального времени - Complete Preemption в действии

После применения lowlatency-патчей от Инго Молнара, я отметил существенный прирост отзывчивости системы по сравнению с обычным режимом (например, Preemptible Kernel). Стабильность системы от этого не пострадала и всё работало, как и прежде. Это вселяло оптимизм и желание дальнейших экспериментов.


Мотивация
Патчи с CFS, добавляющие отзывчивость системе, оставили противоречивые впечатления: да, повышение отзывчивости есть, особенно если загрузить после этого дефолтное ядро. Но музыка при высоких вычислительных и особенно дисковых нагрузках на ноутбуке начала заикаться (даже при запуске XMMS в RT-режиме через sudo), что очень неприятно.

На ноутбуках высокая производительность особенно не нужна, да её и не добиться с такой медленной дисковой подсистемой. Кажется логичным пожертвовать некоторой производительностью во имя более быстрой реакции системы на работу с приложениями. Короче, хочется и с кучей приложений одновременно работать, и архивами ворочать, и музыку слушать - и чтобы в лирические композиции CPU планировщик не вставлял лишних театральных пауз :-)

Поэтому я решил пойти дальше и использовать патчи реального времени (Realtime - Complete Preemption). Патч огромный, около 2Мб, выкачивал отсюда, накладывал на ядро 2.6.22.1. Наложилось и собралось без ошибок.


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

General setup --- Choose SLAB allocator (SLAB)

Так же ставим Полностью Честный Планировщик для ввода-вывода:

Block layer -- Default I/O scheduler (CFQ)

В разделе Processor type and features самые заметные изменения:

Processor type and features --- [*] Tickless System (Dynamic Ticks)
RCU implementation type: (Preemptible RCU)

This option reduces the latency of the kernel by 'threading' hardirqs. This means that all (or selected) hardirqs will run in their own kernel thread context. While this helps latency, this feature can also reduce performance.

Processor type and features --- Preemption Mode (Complete Preemption (Real-Time))

Хотя в справке по этому параметру честно предупреждают, что если не уверены - говорите нет, я таки отметил эту опцию (так как она увеличивает отзывчивость).
Всё, теперь у нас ядро реального времени. После загрузки моё ядро теперь называется так:

# uname -a
Linux notebeast 2.6.22.1-rt9 #1 PREEMPT RT Thu Aug 23 17:20:21 MSD 2007 i686 GNU/Linux

Изменения в работе - Realtime ядро в действии
Ядро стало грузиться медленнее: 51 секунда против 43, даже при включённой concurrent-mode shell загрузке, при которой стартовые скрипты выполняются параллельно.

В логах dmesg появились угрожающие записи:

WARNING: experimental RCU implementation.

Кроме того, при загрузке повторяются сообщения о нестабильности отсчёта времени:

Clocksource tsc unstable (delta = -150284361 ns)

Ладно, несколькими секундами загрузки я пожертвую, но что изменилось в работе? Многое...

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

top - 20:05:35 up 36 min, 1 user, load average: 2.03, 1.58, 1.31
Tasks: 116 total, 2 running, 113 sleeping, 1 stopped, 0 zombie
Cpu(s): 97.0%us, 2.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st
Mem: 498996k total, 416492k used, 82504k free, 15044k buffers
Swap: 801120k total, 33860k used, 767260k free, 232220k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7834 beast 20 0 189m 89m 15m R 92.8 18.4 2:11.13 firefox-bin
6979 root RT 0 69920 9396 4888 S 3.3 1.9 1:05.68 xmms
5338 root 20 0 313m 15m 4324 S 1.3 3.1 0:39.64 Xorg
67 root -51 -5 0 0 0 S 0.3 0.0 0:06.63 IRQ-9
3886 root -51 -5 0 0 0 S 0.3 0.0 0:02.08 IRQ-21
5044 root 30 10 1572 464 428 S 0.3 0.1 0:00.55 cpudynd
5418 beast 20 0 5976 1684 1304 S 0.3 0.3 0:14.49 conky
26970 beast 20 0 2228 1148 856 R 0.3 0.2 0:00.02 top
1 root 20 0 1576 480 452 S 0.0 0.1 0:00.77 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 posix_cpu_timer
4 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 softirq-high/0
5 root -51 -5 0 0 0 S 0.0 0.0 0:04.13 softirq-timer/0
6 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 softirq-net-tx/
7 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 softirq-net-rx/
8 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 softirq-block/0
9 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 softirq-tasklet
10 root -51 -5 0 0 0 S 0.0 0.0 0:00.00 softirq-sched/0
11 root -51 -5 0 0 0 S 0.0 0.0 0:00.97 softirq-hrtimer
12 root -51 -5 0 0 0 S 0.0 0.0 0:00.26 softirq-rcu/0
13 root 10 -10 0 0 0 S 0.0 0.0 0:00.02 desched/0
14 root -2 -5 0 0 0 S 0.0 0.0 0:00.09 events/0
15 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
64 root 15 -5 0 0 0 S 0.0 0.0 0:00.19 kblockd/0
65 root 15 -5 0 0 0 S 0.0 0.0 0:02.10 kacpid
66 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpi_notify
187 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ksuspend_usbd
190 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khubd
192 root 15 -5 0 0 0 S 0.0 0.0 0:00.02 kseriod
209 root 20 0 0 0 0 S 0.0 0.0 0:00.02 pdflush
210 root 20 0 0 0 0 S 0.0 0.0 0:00.39 pdflush

При этом играет музыка в XMMS (запущен с повышенными привилегиями RT), а Firefox пересортировывает дерево захваченных страниц (около 600Мб, занимает 4-5 минут, полная загрузка процессора). Перед этим я быстро, одно за другим, запустил для пробы OpenOffice.Writer, GiMP, Acroreader, Firefox, Thunderbird и Kate (горячими клавишами). Винчестер работал интенсивно, но музыку оборвать так и не удалось.

Выкатил другую дальнобойную артиллерию: запустил QEMU со ЗломХП, поставил три архиватора одновременно (для создания резервных копий). XMMS этого не заметил совершенно, а я в это время писал эту заметку в Scribefire плагине Огнелиса, закрывая время от времени ненужные приложения.

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


Немного объективности
Сам Инго Молнар провёл ряд очень интересных тестов, например эти данные определённо представляют интерес. Это только подтверждает визуальные наблюдения: выигрыш по отзывчивости с RT-ядром значителен. Так же интересные данные о гладкости работы 3D-игр есть тут. Подробное обсуждение того, какой патч (lowlatency или RT) когда лучше есть здесь.


Выводы
Ну что сказать... я впечатлён :-) Уменьшение латентности системы с Realtime-патчем субъективно имеет место быть, по сравнению с lowlatency - и это заметил не я один: Роман Химов поделился своими впечатлениями

Впечатления сугубо положительные. Разница с обычным 2.6.22 в отзывчивости есть и ощутимая, особенно при серьёзной загрузке процессора. Athlon XP 1700+ от этого, конечно, не стал Turion 64 X2, но изменения радуют.

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

Эти результаты могут разниться на разных машинах, и чтобы составить своё мнение об этом, лучше всего собрать два ядра: с lowlatency и Realtime патчами, а для контроля ещё поставить дистрибутивное ядро. И попробовать поработать по очереди под всеми тремя, включив свой любимый аудиоплеер и нагружая систему вычислительными и дисковыми операциями.