Сборка ядра Linux и новый рекорд скорости загрузки
В пятницу планировал снова пойти в лес на прогулку. Но, как всегда, стоит что-либо запланировать, как тут же находится причина сделать все иначе. В этот раз все началось с того, что ПНБ на форуме IntB задал мне вопрос, связанный со сборкой ядра Linux. В поисках ответа на этот вопрос я вспомнил, что у меня на дачном ноутбуке лежат исходники ядра, которые я выкачал их еще перед первым заездом из соображений «будет время — поизучаю», но потом благополучно о них забыл.
И вот в среду вечером пришла в голову мысль, почему бы не собрать свое ядро. Но увы, было слишком поздно, поэтому сборку я отложил на четверг. Как всегда, главными целями были экономия памяти и ускорение загрузки. Последний раз я пытался это сделать летом то ли прошлого, то ли позапрошлого года, но не получилось: ядро выдавало панику на этапе загрузки, а терпения разбираться, почему, у меня тогда не хватило. На этот раз решил идти более консервативным путем: не отключать сразу кучу всего, а взять за основу defconfig и дальше убирать или выносить в модули все пошагово. К моему удивлению, на этот раз все сработало, и новое ядро загрузилось! Причем оказалось, что грузится оно ощутимо быстрее штатного: что-то около 2 секунд вместо шести (речь идет о загрузке kernelspace).
Но вскоре выяснилось, что не все так хорошо, как казалось сначала: новое ядро не видит WiFi от слова совсем. Какое-то время ушло на то, чтобы порывшись в настройках ядра, найти там раздел с нужными драйверами и включить их. Но через пару перезагрузок я вдруг обнаружил, что время загрузки вдруг снова выросло до 6 секунд, и дело явно не в WiFi-драйвере. В результате остаток дня прошел в поисках возможных причин. И только глубокой ночью я вдруг вспомнил про то, как в городе отсутствие swap на Ubunutu 18 приводило к 30-секундному простою при загрузке. А поддержку swap я во время экспериментов с ядром как раз взял и выключил! Включил обратно, пересобрал, перезагрузился — лишние три секунды исчезли!
Потом еще экспериментировал с разными настройками безопасности: включал и отключал их, чтобы посмотреть, как это влияет на производительность. Оказалось, что включение запрета на отображение ядра в userspace ведет к весьма ощутимому падению скорости. Остальное влияет мало (если только не пересобирать весь дистрибутив без PIC/PIE-кода). За всеми этими экспериментами засиделся до пяти утра. Эх, прямо таки стереотипное красноглазие: бессонная ночь и консоль с потоком сообщений компилятора!
А в пятницу по каким-то непонятным причинам проснулся гораздо раньше, чем обычно в последнее время, где-то около 12 часов. Решил воспользоваться тем, что погода улучшилась, и пойти наконец-то в лес пособирать малину. Но перед этим вспомнил про то, что вчера так и не проверил работу с новым ядром нескольких устройств: Web-камеры, cardreader и мобильника в режиме модема при подключении по шнурку. Cardreader заработал сразу, а вот для остального пришлось подключать дополнительные модули и пересобирать ядро еще раз. Причем я толком не знал, что именно нужно, поэтому пошел таким путем: сначала делал модулями все, что хоть как-то имело отношение к тому, что нужно, а потом смотрел список, какие модули оставались загруженными, и оставлял только их.
Потом ушел на прогулку (ее опишу в отдельном сообщении). А когда вернулся и вновь занялся экспериментами с ядром. Наконец-то разобрался с вопросом, почему при попытке избавиться от initramfs получается kernel panic, даже несмотря на то, что все необходимые драйвера и модули вкомпилированы в ядро. Дело оказалось в том, что нужно указывать UUID раздела, а не файловой системы (я прежде вообще не знал, что они отличаются). После этого стало ясно, что основной оставшийся источник задержек при загрузке — это драйвер дискретной видеокарты nouveau. Немного подумав, я взял и отключил его вообще.
И вот, перезагрузившись, я увидел скорость, которая еще недавно казалась мне нереальной: по данным systemd время загрузки составляло чуть больше 1.2 сек. kernelspace и 1.0 сек. userspace, суммарно же меньше 2.3 секунды! Впервые мне удалось получить более хорошие показатели, чем у связки PC DOC 7.0 + Windows 3.11 на Pentium, которая была для меня эталоном быстроты! Причем это была не просто какая-нибудь экспериментальная система, а вполне реально работающая и поддерживающая все имеющиеся устройства, кроме дискретной видеокарты. Причем памяти она занимала всего 134 Мб против 181 при использовании штатного ядраю. Эх, во времена Pentium III такая экономия была бы просто прорывом. А сейчас, увы, этого разве что на лишнюю вкладку в броузере хватит…
Казалось бы, нужно сделать скриншот и закончить на этом эксперименты с ядром, вернувшись к обыденной жизни, но увы. Мысль о дискретной видеокарте не давала мне покоя, поэтому в субботу я снова занялся экспериментами с ядром. Сначала выяснил, что использование дискретной карты с nouveau приводит к отключению аппаратного ускорения в броузере (а если включить его принудительно — к весьма эффектным глюкам), без которого на дискретной карте показатели даже хуже, чем на встроенной с включенным ускорением. Поэтому осталась последняя надежда — пропиертарные драйвера от nVidia.
Увы, здесь меня ждало разочарование. Драйвера из дистрибутива собираться с новым ядром не хотели категорически. Я решил пойти другим путем — скачать драйвер с самого сайта nVidia. Скачал версию 390. Сначала все было хорошо: все установилось и собралось без проблем. Но при загрузке X Server драйвер почему-то не использовался. Из логов было видно, что X Server сначала загружает его, потом выгружает без каких-либо внятных объяснений, и вместо этого берет драйвер встроенной карты. После нескольких попыток сделать с этим хоть что-нибудь я решил попробовать другую версию — 340 (384-ой, увы, на сайте не было). Но с ней и вовсе получилось непонятно: если в каталоге с исходниками ядра был файл .config, она отказывалась собираться, ругаясь source is not clean, а при его отсутствии ругалась на то, что в ядре выключена поддержка модулей (при попытке включить которую создавался новый .config и история повторялась сначала). Потом еще были попытки собрать более новую версию nouveau из исходников на его сайте, попытки оптимизировать время загрузки обычного nouveau, задавая разные параметры командной строки, но все безрезультатно. В итоге пока что отключил его полностью, и все.
Но несмотря на это, я снова чувствую себя Настоящим Компьютерщиком, который знает и контролирует то, что происходит в его системе, а не воспринимает ее как некий черный ящик.
И вот в среду вечером пришла в голову мысль, почему бы не собрать свое ядро. Но увы, было слишком поздно, поэтому сборку я отложил на четверг. Как всегда, главными целями были экономия памяти и ускорение загрузки. Последний раз я пытался это сделать летом то ли прошлого, то ли позапрошлого года, но не получилось: ядро выдавало панику на этапе загрузки, а терпения разбираться, почему, у меня тогда не хватило. На этот раз решил идти более консервативным путем: не отключать сразу кучу всего, а взять за основу defconfig и дальше убирать или выносить в модули все пошагово. К моему удивлению, на этот раз все сработало, и новое ядро загрузилось! Причем оказалось, что грузится оно ощутимо быстрее штатного: что-то около 2 секунд вместо шести (речь идет о загрузке kernelspace).
Но вскоре выяснилось, что не все так хорошо, как казалось сначала: новое ядро не видит WiFi от слова совсем. Какое-то время ушло на то, чтобы порывшись в настройках ядра, найти там раздел с нужными драйверами и включить их. Но через пару перезагрузок я вдруг обнаружил, что время загрузки вдруг снова выросло до 6 секунд, и дело явно не в WiFi-драйвере. В результате остаток дня прошел в поисках возможных причин. И только глубокой ночью я вдруг вспомнил про то, как в городе отсутствие swap на Ubunutu 18 приводило к 30-секундному простою при загрузке. А поддержку swap я во время экспериментов с ядром как раз взял и выключил! Включил обратно, пересобрал, перезагрузился — лишние три секунды исчезли!
Потом еще экспериментировал с разными настройками безопасности: включал и отключал их, чтобы посмотреть, как это влияет на производительность. Оказалось, что включение запрета на отображение ядра в userspace ведет к весьма ощутимому падению скорости. Остальное влияет мало (если только не пересобирать весь дистрибутив без PIC/PIE-кода). За всеми этими экспериментами засиделся до пяти утра. Эх, прямо таки стереотипное красноглазие: бессонная ночь и консоль с потоком сообщений компилятора!
А в пятницу по каким-то непонятным причинам проснулся гораздо раньше, чем обычно в последнее время, где-то около 12 часов. Решил воспользоваться тем, что погода улучшилась, и пойти наконец-то в лес пособирать малину. Но перед этим вспомнил про то, что вчера так и не проверил работу с новым ядром нескольких устройств: Web-камеры, cardreader и мобильника в режиме модема при подключении по шнурку. Cardreader заработал сразу, а вот для остального пришлось подключать дополнительные модули и пересобирать ядро еще раз. Причем я толком не знал, что именно нужно, поэтому пошел таким путем: сначала делал модулями все, что хоть как-то имело отношение к тому, что нужно, а потом смотрел список, какие модули оставались загруженными, и оставлял только их.
Потом ушел на прогулку (ее опишу в отдельном сообщении). А когда вернулся и вновь занялся экспериментами с ядром. Наконец-то разобрался с вопросом, почему при попытке избавиться от initramfs получается kernel panic, даже несмотря на то, что все необходимые драйвера и модули вкомпилированы в ядро. Дело оказалось в том, что нужно указывать UUID раздела, а не файловой системы (я прежде вообще не знал, что они отличаются). После этого стало ясно, что основной оставшийся источник задержек при загрузке — это драйвер дискретной видеокарты nouveau. Немного подумав, я взял и отключил его вообще.
И вот, перезагрузившись, я увидел скорость, которая еще недавно казалась мне нереальной: по данным systemd время загрузки составляло чуть больше 1.2 сек. kernelspace и 1.0 сек. userspace, суммарно же меньше 2.3 секунды! Впервые мне удалось получить более хорошие показатели, чем у связки PC DOC 7.0 + Windows 3.11 на Pentium, которая была для меня эталоном быстроты! Причем это была не просто какая-нибудь экспериментальная система, а вполне реально работающая и поддерживающая все имеющиеся устройства, кроме дискретной видеокарты. Причем памяти она занимала всего 134 Мб против 181 при использовании штатного ядраю. Эх, во времена Pentium III такая экономия была бы просто прорывом. А сейчас, увы, этого разве что на лишнюю вкладку в броузере хватит…
Казалось бы, нужно сделать скриншот и закончить на этом эксперименты с ядром, вернувшись к обыденной жизни, но увы. Мысль о дискретной видеокарте не давала мне покоя, поэтому в субботу я снова занялся экспериментами с ядром. Сначала выяснил, что использование дискретной карты с nouveau приводит к отключению аппаратного ускорения в броузере (а если включить его принудительно — к весьма эффектным глюкам), без которого на дискретной карте показатели даже хуже, чем на встроенной с включенным ускорением. Поэтому осталась последняя надежда — пропиертарные драйвера от nVidia.
Увы, здесь меня ждало разочарование. Драйвера из дистрибутива собираться с новым ядром не хотели категорически. Я решил пойти другим путем — скачать драйвер с самого сайта nVidia. Скачал версию 390. Сначала все было хорошо: все установилось и собралось без проблем. Но при загрузке X Server драйвер почему-то не использовался. Из логов было видно, что X Server сначала загружает его, потом выгружает без каких-либо внятных объяснений, и вместо этого берет драйвер встроенной карты. После нескольких попыток сделать с этим хоть что-нибудь я решил попробовать другую версию — 340 (384-ой, увы, на сайте не было). Но с ней и вовсе получилось непонятно: если в каталоге с исходниками ядра был файл .config, она отказывалась собираться, ругаясь source is not clean, а при его отсутствии ругалась на то, что в ядре выключена поддержка модулей (при попытке включить которую создавался новый .config и история повторялась сначала). Потом еще были попытки собрать более новую версию nouveau из исходников на его сайте, попытки оптимизировать время загрузки обычного nouveau, задавая разные параметры командной строки, но все безрезультатно. В итоге пока что отключил его полностью, и все.
Но несмотря на это, я снова чувствую себя Настоящим Компьютерщиком, который знает и контролирует то, что происходит в его системе, а не воспринимает ее как некий черный ящик.