Ядро 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 патчами, а для контроля ещё поставить дистрибутивное ядро. И попробовать поработать по очереди под всеми тремя, включив свой любимый аудиоплеер и нагружая систему вычислительными и дисковыми операциями.

12 комментариев: |высказаться!| RSS-лента дискуссии.|
jetxee комментирует...

Спасибо за пост. Понравилась ссылка на замер частоты кадров в Quake с параллельной нагрузкой на ядре с CFS и без. 3D у меня иногда дёрганное.

Что касается непрерывающейся музыки, то она у меня не прерывается и так, на обычном ядре, правда расчёты запускаю с положительным nice.

Анонимный комментирует...

Clocksource tsc unstable это ухудшение ядра, а не следствие патча. У меня с ним тоже начинаются тормоза. CFS еще не пробовал - буду ждать до ядра 2.6.24 :)

http://kerneltrap.org/node/8306

virens комментирует...

2 jetxee пишет...
Понравилась ссылка на замер частоты кадров в Quake с параллельной нагрузкой на ядре с CFS и без.
Да, впечатляет. Так как у меня Q3 нет, решил сослаться на Молнара - ему виднее, в конце концов :-)

Что касается непрерывающейся музыки, то она у меня не прерывается и так, на обычном ядре, правда расчёты запускаю с положительным nice.
Я тоже запускаю с положительным, но так как расчёты численные - они требуют данных, записанных в виде многомегабайтных картинок. И тут начинается :-)

2 Анонимный пишет...
Clocksource tsc unstable это ухудшение ядра, а не следствие патча.
Мммм... там в ссылке (кстати, большое спасибо) говорят, что это из-за способности процессора быстро менять частоту.

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

portnov комментирует...

У меня на довольно стареньком домашнем компе музыку даж на ванильном ядре затормозить сложно :) Вот щас: компиляется inkscape, в qemu запущена убунта, раз-bz2-иповываются два десятка 19-Мб tif-ов, я уж не говорю что открыто два окна браузера, liferea и прочее по мелочи (OpenOffice и Gimp). Немножко подтормаживает рендеринг страниц в epiphany, но вполне терпимо. Audacious всего этого не замечает. 2.6.21 ванильное, самосборное (почти монолитное), Cel 2Hz, Sis-овская материнка и пр.

virens комментирует...

2 portnov пишет...
У меня на довольно стареньком домашнем компе музыку даж на ванильном ядре затормозить сложно :)
У меня тоже много чего бывает запущено, и на фоне МАТЛАБ обрбатывает фотографии 4000х3000. Система по-любому лезет в своп, памяти не хватает, своп раздувается, винчестер с ума сходит...

На большой машине этих проблем, естественно, нет.

Максим комментирует...

А если так потестить: взять 16 битную досовую прогу и запустить ее на ЗлоХР в эмуляторе?
VirtualBox на родном ядре Убунты почти вешает систему, минут 5 проходит, пока доберусь до консоли и сниму процесс. :)

Например тот-же rar для DOS версии этак 2.0

Nikolay комментирует...

А что за проблема с нотбучными винчестерами?

Тестирую стационарный SATA диск:
[20:15 /home/nik]# hdparm -tT /dev/sda (5317: KOI8-R)

/dev/sda:
Timing cached reads: 1672 MB in 2.00 seconds = 834.88 MB/sec
Timing buffered disk reads: 176 MB in 3.00 seconds = 58.58 MB/sec

Теперь ноутбучный PATA:

[20:16 /home/nik/tmp/tkabber-svn]# hdparm -tT /dev/hda (root@laptop.niksite.ru: KOI8-R)

/dev/hda:
Timing cached reads: 1006 MB in 2.00 seconds = 502.65 MB/sec
Timing buffered disk reads: 130 MB in 3.02 seconds = 43.01 MB/sec

Разница всего в полтора раза, не сказать, чтобы очень уж принципиальная. Или надо было с рейдами из свежевыпущенных SATAII 500ок сравнивать?

virens комментирует...

2 Nikolay пишет...
А что за проблема с нотбучными винчестерами?
А такая проблема, что по скорости произвольного доступа они сливают десктопным собратьям, как и контроллеры, стоящие в ноутах. Может, у вас hi-end система, конечно, но в ноутах среднего ценового диапазона под капотом точно не WD Raptor :-)

Ni@m комментирует...

У меня подобная проблема со звуком с cfs(без него также с последними ядрами), но не с аудио проигрывателями, а с видео(mplayer, xine) - звук рыпается(что интересно, что в Totem'е все отлично), и как я выяснил - дело в alsa. Игно посоветовал мне продебажить alsa, но у меня пока нет времени на это.
Экспериментальным путем я выяснил, что если как audio output систему поставить sdl - то в тех же приложениях все со звуком отлично. Это, конечно, не решает проблему, но кому хочется нормального звука - испробуйте.
А я тем временем попробую таки раскопать чтож таки с alsa стряслось(есть подозрение на вытеснение), ну а если кто-то поможет - и того быстрее решим эту несправедливость =)

Nikolay комментирует...

> Может, у вас hi-end система,
> конечно, но в ноутах среднего
> ценового диапазона под капотом
> точно не WD Raptor :-)

Дак по дефолту в моём ноутбуке действительно стоял какой то довольно тормозной диск на 40 гигабайт. Коий был самостоятельно заменен на SAMSUNG HM160JC, 160 гигабайтный, PMRный, один из самых быстрых (по линейному чтению) пятитысячников. Прирост производительности был весьма заметен.

Victor Sergienko комментирует...

Latency - это не латентность, а запаздывание.

DM комментирует...

На Asus A6Tc имеем с винтом

# hdparm -tT /dev/hdc

/dev/hdc:
Timing cached reads: 1374 MB in 2.00 seconds = 687.11 MB/sec
Timing buffered disk reads: 108 MB in 3.02 seconds = 35.77 MB/sec

Отправить комментарий

Подписаться на RSS-ленту комментариев к этому посту.