CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
13.12.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки :: Заметки о ядре

Лишнему в ядре не место

До сих пор все конкретные примеры конфигурирования ядра относились к дистрибутиву Zenwalk. Штатный метод его загрузки — использование инициирующего диска в памяти, initrd. Однако на более-менее стандартном "железе" и при использовании одной из общепринятых файловых систем в качестве корневой ядро с дистрибутивного носителя, устанавливаемое по умолчанию, может загрузиться и без него — правда, при этом потеряются стартовые красоты типа сплэш-картинки.

Для загрузки ядра "напрямую", без initrd, всего-то и требуется, чтобы в него была жестко (не модулями!) встроена поддержка корневой файловой системы и дискового контроллера, на котором она расположена. И для спокойствия души это следует проконтролировать. Заодно можно избавиться от поддержки ряда устройств, отсутствующих в подавляющем большинстве компьютеров — правда, большинство из них и так включены как модули, и вроде бы есть не просят, но зачем держать у себя заведомо ненужные вещи?

Кроме того, на современной машине, часто имеющей в своём составе только SATA-накопители (в том числе и SATA-приводы оптических дисков), открывается уникальная возможность освободить ядро и от поддержки массы морально устаревших чипсетов и интерфейсов, тем самым существенно (процентов на 20-25%) сократив объем файла образа ядра.

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

В первый эффект действительно можно было бы поверить, хотя он не так уж принципиален: при нормальной эксплуатации настольной Unix-машины (о ноутбуках здесь речь не идёт, у них свои требования) в домашних условиях она загружается не чаще, чем раз в сутки, а в служебных — так и много реже.

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

Однако прошли годы, формальное быстродействие компьютеров возросло во многие разы, объемы оперативной памяти — на порядки. И нынче, если разницу в скорости загрузки ядра большого и ядра маленького еще можно увидеть невооруженным глазом, то на реальных задачах она будет видна разве что в телескоп, обращенный к "Пяти звёздочкам".

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

И тем не менее, занятие по оптимизации ядра не такое уж бессмысленное, как может показаться.

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

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

И в-третьих, это действительно спорт — увлекательный и азартный. Так что продолжим наши игры с ядром...

Для начала убедимся, что в нашем ядре имеется всё, что нужно для его автономной, без initrd, загрузки. И тут перво-наперво нам потребуется пункт Device drivers из главного меню скрипта конфигурирования (рис. 1).


Рис. 1. Находим драйверы устройств...

В развернувшемся подменю (рис. 2) взгляд сразу останавливается на пунктах Block devices и Misc devices.


Рис. 2. ... и начинаем со второстепенных

Раскрыв первый из них (рис. 3), мы можем освободиться от поддержки флоппи-дисковода и еще некоторых столь же нужных устройств, заодно проверив, что поддержка устройств loopback-типа наличествует — в виде модуля, как на приведенной картинке, или встроенной. Она подчас необходима — например, для монтирования образов CD/DVD, — но необходима достаточно редко, и потому модульная её поддержка предпочтительна.


Рис. 3. Убираем поддержку ненужных блочных устройств...

Также не лишней может оказаться поддержка низкоскоростных USB-устройств и пакетной записи на CD/DVD (запись в формате UDF) — разумеется, модулями, ибо и то, и другое отнюдь не предмет каждодневого назначения. А вот поддержку RAM-дисков, коль скоро мы решили обходиться без initrd, искореняем как класс, полностью (рис. 4).


Рис. 4. ... в том числе RAM-дисков

В пункте, посвященном разнообразным (misc) устройствам, стоит избавиться от поддержки расширений для лаптопов разнообразных моделей (рис. 5): ведь даже если наша система и крутится на ноутбуке, то наверняка на каком-либо одном, а не на всех сразу.


Рис. 5. Поддержка лишних лаптопов нам тоже ни к чему

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

Зона особого внимания концентрируется в трёх последовательных пунктах (см. рис. 2):

ATA/ATAPI/MFM/RLL support
SCSI device support
Serial ATA (prod) and Parallel ATA (experimental) drivers

До недавнего времени главным из них был первый, ибо все основные накопители в настольных машинах подсоединялись к IDE-разъёмам (ныне за ними закрепилось погоняло — накопители с PATA-интерфейсом). Устройства SCSI выполняли сугубо вспомогательные функции — под них маскировались флэшки, встроенные накопители цифровых камер, а одно время и пишущие CD/DVD-приводы. Что же до SATA-дисков, то первое после своего появления время их поддержка обеспечивалась опциями пункта первого (хотя сами они номенклатурно тоже примазывались к славе SCSI-устройств).

Ныне совместная поддержка SATA- и PATA-накопителей обеспечивается так называемой подсистемой libdata SATA, использующей подсистему SCSI (таким образом, PATA-диски и компакт-приводы также попали в SCSI-номенклатуру), в результате чего на первые роли при конфигурировании вышли пункты 3 и 2. Соответственно, с них-то мы и начнём.

В пункте про SCSI-устройства нам, по большому счёту, необходимы только такие опции:

  • общая поддержка SCSI-устройств (SCSI device support);
  • поддержка SCSI-винчестеров (SCSI disk support);
  • поддержка оптических накопителей SCSI (SCSI CDROM support).

Причём все они должны быть встроены в ядро (рис. 6).


Рис. 6. Поддержка SCSI — всё, что нужно для счастья

Если наша система загружается с аппаратного SATA RAID, аналогично, видимо, нужно поступить с пунктом RAID Transport Class — я этого не проверял по причине неиспользования аппаратных RAID-массивов, а подсказка по этому пункту словообилием не отличается.

Наконец, в некоторых случаях может потребоваться еще и драйвер родовых устройств SCSI (т.н. SCSI generic — sg); соответствующую опцию подключаем в качестве модуля.

В результате всех этих действий в итоговом файле .config по завершении настройки должны присутствовать такие строки:

CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
...
CONFIG_BLK_DEV_SD=y
...
CONFIG_BLK_DEV_SR=y
...
CONFIG_CHR_DEV_SG=m

При использовании аппаратного RAID к ним, видимо, добавится строка

CONFIG_RAID_ATTRS=y

И это всё, что необходимо для счастья: прочие опции, включая бессчетное число низкоуровневых SCSI-драйверов (SCSI low-level drivers), можно безбоязненно отключить.

Итак, верхний уровень обслуживания SCSI-номенклатуры включён. Тперь озаботимся потребностями уровня более низкого — то есть собственно SATA-устройств, ради которых всё и затевалось. Для чего, открыв пункт Serial ATA (prod) and Parallel ATA (experimental) drivers (рис. 7), начинаем убирать в нём поддержку всех чипсетов и контроллеров, кроме имеющихся в наличии. В нашем случае это будет встроенная в ядро поддержка чипсетов Intel, при использовании чипсетов Nvidia или ATI/AMD аналогично следует поступить с ними. И, разумеется, надо оставить поддержку родового класса ATA-устройств (Generic ATA support).


Рис. 7. Оставляем только необходимые устройства SATA

А что же пункт поддержки устройств ATA/ATAPI/MFM/RLL? Он нам больше не нужен, и поэтому мы отключаем его напрочь.

Вообще-то в пункте Device Drivers из главного меню есть где порезвиться шаловливым ручонкам. Однако это рукоблудие мы оставим для другого раза. А в контексте настоящего разговора остановимся ещё только на одном его подпункте — поддержке многодисковых устройств (Multiple devices driver support), под которыми понимаются программные RAID-массивы и тома системы LVM. Если ни то, ни другое не используется, то весь этот подпункт можно истребить на корню. Если используется как загрузочное устройство — встроить в ядро. Если загрузки ни с того, ни с другого типа устройств не намечается — можно подключить и как модули. Причем для soft-RAID в любом случае достаточно ограничиться поддержкой массивов только того уровня, который будет использоваться на деле — например, RAID-0 под файловую систему для домашнего каталога (рис. 8).


Рис. 8. Модульная поддержка RAID-0

Покончив с устройствами, которые потенциально могут выступать в качестве загрузочных, и заодно искоренив устройства заведомо ненужные, переходим к не менее важному моменту — поддержке файловых систем, за которую отвечает одноименный ( File systems) пункт главного меню (рис. 9).


Рис. 9. Поддержка файловых систем

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

Убеждаемся, что в этом отношении всё нормально: в дистрибутивном ядре Zenwalk'а встроены все пригодные для несения корня файловой иерархии файловые системы --ext2/ext3, ReiserFS, XFS, лишь JFS задействована как модуль. И теперь можем как отключить заведомо ненужные файловые системы (я, например, отключаю вышеупомянутую JFS и всё, связанное с NFS), так и подключить дополнительные (так, для любителей экспериментов доступна экспериментальная поддержка файловой системы ext4).

Второстепенные файловые системы, типа ISO-9660 и UDF для оптических дисков и FAT/VFAT — для накопителей типа флэшек, целесообразно подключить как модули. Вероятно, это верно и в отношении NTFS — за неактуальностью изучением этого вопроса не занимался.

А вот что заслуживает отдельного внимания — это поддержка псевдофайловых систем (или файловых псевдо-систем, иногда не вполне точно называемых виртуальными). Здесь следует позаботиться о включении в ядро поддержки таких файловых систем, как /proc и всех ее разновидностей, sysfs и собственно виртуальной файловой системы в оперативной памяти (Virtual memory file system), именуемой также shm fs или tmpfs (рис. 10); впрочем, обычно это уже сделано по умолчанию.


Рис. 10. Поддержка псевдо-файловых систем

Наконец, последнее, что имеет отношение к файловым системам — пункт Native language support. Он не влияет ни на локаль, ни на поддержку национальных языков системой и приложениями, а отвечает только за возможность восприятия имен файлов, записанных в наборах символов, отличных от ASCII. Если следовать советам резонных людей и не иметь дела с файлами, именованными чем бы то ни было кроме чистой "латиницы" (они будут прочитаны в любом случае), этот пункт можно просто игнорировать. Но, поскольку мы живём не в безвоздушном пространстве, время от времени устройства с такими файлами будут попадать в наши руки. Поэтому весь этот мункт целесообразно включить как модуль, и модульно же задействовать отдельные его подпункты, имеющие практическое значение в наших условиях, как то:

  • Codepage 437 (США и Канада);
  • Codepage 866 ("альтернативная" кириллица);
  • Windows CP1251 (кодировка сами знаете чего);
  • ASCII — чисто для порядка;
  • NLS ISO 8859-1, или Latin 1 — аналогично;
  • NLS ISO 8859-5 (бывшая кириллица по ГОСТу, используемая в Solaris) — на всякий пожарный случай;
  • NLS KOI8-R (до недавнего времени самая распространенная кодировка кириллицы в свободных Unix'ах и Интернете);
  • NLS KOI8-U/RU (её аналог для братских Украины и Белоруссии);
  • NLS UTF-8 — тот самый универсальный железный конь, который постепенно идёт на смену разномастным табунам национальных чарсетов.

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

Для начала — про обещанное уменьшение объема файла образа: да, что есть, то есть: если дистрибутивное ядро Zenwalk'а тянуло на 1,9 Мбайт (а его модификация, собранная в прошлой заметке, была почти такой же), то нынче мы видим образ размером 1,6 Мбайт. За счёт этого мы вправе ожидать некоторого выигрыша в скорости загрузки машины, не так ли?

Нет, не так. Система о нашем праве не подозревает и грузится с завидно постоянной скоростью, вне зависимости от ядра (замерялось секундомером от выбора в меню GRUB до предложения авторизоваться, для умолчального ядра, ядра, собранного в прошлой заметке, и ядра нынешнего): около 13 секунд при загрузке в чистую консоль (runlevel по умолчанию — 3) и примерно 20 секунд — при загрузке в gdm (runlevel 4).

Неожиданный результат? Если подумать, то нет. Потому что приходится констатировать: на современных машинах разница в скорости загрузки собственно ядрер различного размера столь мала, что полностью нивелируется временем подгрузки модулей, запуска стартовых серверов, обращения к DHCP, синхронизации с серверами точного времени по NTP. Не говоря уже о времени старта X-сервера и менеджера сеансов при runlevel 4...

Предвижу возражение, которое может показаться резонным: для сравнения чистого времени загрузки различных ядер следует исключить внимание всех осложняющих этот процесс факторов, вроде перечисленных выше.

Возражение отметается с негодованием простым вопросом: а за каким зелёным нам нужна загрузка без необходимых модулей, сети и прочих требуемых при реальной работе сервисов? Вот если бы мы были участниками соревнования на скорость старта машины — тогда да; но ведь таковые пока в олимпийскую программу не включили. А ядро нами пересобиралось вроде как для ускорения повседневной деятельности.

Кстати, а ускорилась ли эта самая повседневная деятельность на новом ядре? Проверяем, в качестве мерила её взяв всё ту же компиляцию ядра (ну есть люди, для которых компиляция составляет если не всю работу, то существенную её часть). И приходим к неутешительным результатам: 15:22 при выполнении команды make all и 7:56 — make -j4 all.

Сравниваем это с показателями из предыдущей заметки и делаем вывод: сокращение объема ядра за счет отключения неиспользуемых опций в современных условиях не даёт никакого прироста быстродействия.

Выходит, что всё, чем мы занимались, зря? Не совсем. Во-первых, мы всё-таки получили (правда, ещё в прошлой заметке) доступ к памяти более 4 Гбайт, что можно считать реальным результатом (в предположении, конечно, что раз мы накупили столько памяти, то она нам на самом деле нужна — например, для работы с очень большими изображениями).

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

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




Комментарии

аноним, Wed Jul 15 12:52:04 2009:
В этом случае с апдейтом тебе придет и новое ядро. В котором все необходимые опции будут включены.
аноним, Sun Feb 8 22:29:43 2009:
Ну а у меня от сборки своего ядра освободилось больше 100 мб ОЗУ,
аноним, Sun Jan 11 09:44:12 2009:
"Сравниваем это с показателями из предыдущей заметки и делаем вывод: сокращение объема ядра за счет отключения неиспользуемых опций в современных условиях не даёт никакого прироста быстродействия."

Эх, жаль...
Но всеравно, считаю, что даже для практики оно полезно.
аноним, Fri Sep 5 11:21:52 2008:
"До недавнего времени главным из них был первый, ибо все основные накопители в настольных машинах подсоединялись к IDE-_разъёемам_ (ныне за ними закрепилось погоняло — _напоители_ с PATA-интерфейсом)."
Орфографические ошибки
Алексей Федорчук, Wed Sep 3 20:47:59 2008:
2 Buy
Один из вариантов.
А можно запретить обновление ядра из пакетов по умолчанию - только вручную
Buy, Wed Sep 3 20:22:55 2008:
Кажется разобрался, просто в GRUB надо прописать эти новые образа, а наш образ без initrd.img отдельной строчкой будет... :)
Buy, Wed Sep 3 20:19:28 2008:
>А вот поддержку RAM-дисков, коль скоро мы решили обходиться без initrd, искореняем как класс, полностью.

А как быть тогда, если с апдейтами приходит очередной initrd.img с соответствующим vmlinuz? Мне например с момента установки Kubuntu 8.04 пришло их еще три: 2.6.24-17, ...-18, ...-19. Я так понял какие-то корекции применялись. И в этом случае их опробовать видимо будет нельзя???

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds