Скомпилирует ли Linux-ядро ускорение ОС?

Скомпилирует ли загруженное linux-ядро (например, 3.2) ускорение ОС (например, ubuntu) на этой конкретной машине?

10
задан 30 January 2012 в 08:54

10 ответов

В общем случае нет.

Однако есть некоторые исключения из «нет». Например, ядро ​​ликрикса или ядро ​​Ubuntu Flavors.

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

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

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

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

См .:

Ядро ликрикса [ ! d10]

9
ответ дан 25 May 2018 в 14:45

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

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

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

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

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

5
ответ дан 25 May 2018 в 14:45

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

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

2
ответ дан 25 May 2018 в 14:45

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

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

0
ответ дан 25 May 2018 в 14:45

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

0
ответ дан 25 May 2018 в 14:45

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

0
ответ дан 31 July 2018 в 10:50

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

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

0
ответ дан 7 August 2018 в 19:48

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

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

0
ответ дан 10 August 2018 в 08:14

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

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

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

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

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

5
ответ дан 15 August 2018 в 20:18

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

0
ответ дан 15 August 2018 в 20:18

Другие вопросы по тегам:

Похожие вопросы: