Компиляция ядра Linux делает ОС быстрее?

В общем, нет.

Есть, однако, некоторые исключения из «нет». Например, ядро ​​ликвора или вкусы ядра Ubuntu . Обычно это настройка производительности, которая может изменить ситуацию (ядро сервера быстрее для серверов и не улучшит производительность рабочего стола).

С Ubuntu, если вы используете правильную версию ядра, вы должны быть в порядке.

Примечание: Ядро Liquorix также имеет некоторые исправления (в дополнение к настройке производительности).

Другое исключение будет, если у вас есть какое-то необычное оборудование.

Но в подавляющем большинстве случаев производительность не является «стандартной» причиной для компиляции ядра.

См .:

Ядро компиляции вики Ubuntu

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

В прошлом месяце я собрал двадцать шесть ядер между двумя машинами, пытаясь настроить производительность. Что я обнаружил:

1. Изменение типа процессора в .config на собственную архитектуру и удаление параметров, поддерживающих другие архитектуры, повысили пропускную способность ввода-вывода файлов более чем на 10% в тестах (достаточно, чтобы я мог «почувствовать» улучшение ») и уменьшена задержка после ввода данных пользователем в XFCE на Xubuntu 12.04 -32bit на моем ноутбуке 1,8 ГГц (K8) Mobile Sempron 512 МБ RAM. Те же изменения не оказали какого-либо количественного или ощутимого влияния на мой ноутбук с оперативной памятью Core2 Duo 2 ГБ 1,73 ГГц в 64-разрядной версии Ubuntu 12.04, но привели к тому, что одно ранее стабильное приложение стало подверженным сбоям.
2. Изменение значения HZ in .config на 1000 значительно улучшило отклик на ввод данных пользователем при высокой загрузке ЦП в обеих системах. Это также сделало изменения фокуса окна X мгновенными при любых условиях.
3. Патч BFS увеличил время автономной работы в обеих системах на несколько минут. Достаточно, чтобы быть измеримым и состоять, но недостаточно, чтобы иметь большое значение. Тесты не выявили статистически значимых изменений производительности, но обе системы «чувствуют» быстрее. Я подозреваю, что это связано с тем, что приоритет планирования более полезен для типичных рабочих нагрузок на этих конкретных машинах.
4. Все остальные попытки .config приводили к снижению производительности в обеих системах.

Я потратил смешные суммы времени на компиляцию и тестирование различных конфигураций. При этом только пять ядер дали желаемый результат из двадцати шести попыток. Семь ядер даже не работали (либо не загружались, либо не запускались X). Я недавно установил ядро ​​Liquorix из репозитория и собрал все вышеперечисленные улучшения, а также примерно на 50% увеличение частоты кадров в обеих играх Windows, в которые я играю через WINE в системе Core2. Это заняло всего несколько минут, и ничего не сломалось.

Моя ОС лучше, потому что я скомпилировал собственное ядро? Ну да, немного. Пока я не найду что-то, что работает медленнее / ломается, потому что я не смог найти это во время тестирования. Моя ОС быстрее? Нет.

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

Тем не менее, это очень много времени, чтобы выбрать только те варианты, которые вам нужны.

Я скомпилировал ядро ​​для EeePC 900A просто для удаления ненужных драйверов и функций, для загрузки без дополнительного initrd, для установки планировщика ввода-вывода по умолчанию, для оптимизации для Atom, а также для отключения отладки и некоторой производительности и отзывчивости ухудшение энергосберегающих функций. (он используется в качестве сервера для различных мелочей). Требуется меньше времени на загрузку ^^ Около года назад я пробовал это раньше, но Chromium показывал только пустые веб-страницы - с кликабельными ссылками ...

Я не знаю, как насчет ядра, но в целом компиляция приложений из исходного кода обычно заставляет их работать быстрее (я обычно делаю это с помощью библиотек разработчиков, таких как CGAL, или приложений, таких как ParaView). Конечно, когда процесс компиляции оптимизирован для архитектуры и т. Д.

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