Зачем компилировать ядро?

Я например компиляю ядро чтобы оно было монолитное, пропатчить драйвер видеокарты для поддержки видеокартой 4К разрешения, потому как в дефолте она прикидывается, что может только в 1920х1080. Можно еще собрать ядро реального времени чтобы звук был без задержек совсем. Кроме того когда нет нужды компилять все модули это происходит в разы быстрее - 5 минут вместо часа например. Когда хочется отключить патчи ядра, снижающие быстродействие, которые защищают от угроз и много чего еще.

А в вашем дебиане всегда так. Если там чего то нет - значит это никому не нужно и вообще ни на что не влияет. Но оно влияло, когда эта фича только появилась, я отмечал разницу между ядрами с 250 и 1000hz визуально, при перемещении окон в КДЕ например. Никакой OpenGL тогда ничего не ускорял и банальный композитинг казался чрезвычайно продвинутой и крутой фишкой. Сейчас наверное действительно разницу можно только в динамических играх почувствовать.

Вот еще свежак

Сборка ядра без 99% драйверов

Я например компиляю ядро чтобы оно было монолитное

Просто чтобы оно таким было, из религиозно-фанатических соображений?

пропатчить драйвер видеокарты для поддержки видеокартой 4К разрешения

Ну, ОК, такое... Что за драйвер, удивлён тем что нужно патчить для этого. Сам 4к не практикую, просто интересно знать на будущее.

Можно еще собрать ядро реального времени чтобы звук был без задержек совсем.

А можно использовать rt ядро для своего дистрибутива, если оно есть. Тоже, такое... Ну ОК.

Кроме того когда нет нужды компилять все модули это происходит в разы быстрее - 5 минут вместо часа например.

А если пользоваться готовым - 0 секунд.

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

Достаточно прописать mitigations=off в параметры загрузки ядра, пересобирать его совсем не обязательно для этого, кроме того в конфиге не все mitigations отключаются.

Хм. А что это за тайно супер возможности, которые не нужны настолько, что легче перекомпелять ядро?

Уже не первый раз на протяжении многих лет задаётся вопрос в лоб - «Зачем компилировать ядро?» И ни разу я не слышал ничего вменяемого. «Не всем нужно то что по дефолту, некоторым нужно нечто особенное» и никакой конкретики. И даже мантры про то, что ядро становится быстрее уже не повторяют.

А в вашем дебиане всегда так. Если там чего то нет - значит это никому не нужно и вообще ни на что не влияет.

А у тебя что за дистрибутив, где по дефолту 1000 герц стоит?

Хм. А что это за тайно супер возможности, которые не нужны настолько, что легче перекомпелять ядро?

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

А там где архитектура стандартная я давно и прекрасно пользуюсь дефолтным ядром и ущербным себя не чувствую. Если ты думаешь меня поджечь на флейм самосбор или дефолт, модули или монолит и т.п. - зря, я не бомбану. Всегда утверждал и утверждаю что от добра добра не ищут, если в готовом дистрибутивном ядре всё работает и всё устраивает - это прекрасно. Правильно говорят, те кто пересобирают ядра сами обычно знают зачем они это делают. А тем кто спрашивает «зачем пересобирать?» пересобирать ядра незачем. Иначе они бы этот вопрос не задавали.

А у тебя что за дистрибутив, где по дефолту 1000 герц стоит?

Calculate Linux

А, ну у них там всё не как у людей. Насколько я помню они и патчи с BFQ раньше накладывали, до того как его в апстрим влили, и ещё что-то. Но в большинстве дистрибутивов это либо 250, либо 300 герц.

я отмечал разницу между ядрами с 250 и 1000hz визуально

Испытания проводил двойным слепым методом? Или поменял и сразу «заметил»?

Сейчас наверное действительно разницу можно только в динамических играх почувствовать

Игры тут вообще не причём. Суть была в том, что изначально к CONFIG_HZ были привязаны все планировщики ядра. С ростом производительности дефолтное значение в 100 (т.е. 10мс) стало слишком большим для планировщика типичного десктопа — мощность процессора позволяла комфортно работать с несколькими задачами, но время переключения между ними упиралось в 10мс интервал между принятиями решений планировщиком. Аналогичная проблема была с планировщиком ввода-вывода — характерные времена задержки у винчестеров упали меньше 10мс. Поэтому сначала добавили вариант с 1000 (1мс), а потом и 250 (4мс), когда выяснилось, что 1000 даёт великоватый оверхэд. Но время шло, росло число ядер (при обработке пользовательского действия во время уже работающей одной задачи теперь не надо ждать принятия решения планировщиком по приостановке этой задачи и отдачи процессора на другую, теперь она просто запускается на свободном ядре с нулевой задержкой), появлялись NCQ и SSD, которые вообще сводили на нет нужду в планировщике в/в, под это всё менялись и планировщики, теперь тот же bfq полностью отвязан от CONFIG_HZ.

Прогнал тест таймеров на Linux 5.8.1, OpenSUSE, результаты нормальные, но хуже, чем у Haiku: https://imgur.com/a/jwdP1QI.

в большинстве дистрибутивов это либо 250, либо 300 герц.

Мне почему то кажется что так только в Дебиане и в серверных дистрибутивах, RHEL\CentOS там... В бубунте кажется 1000, в сусе и федоре тоже, но могу наврать, не уверен. В любом случае там ядер на все случаи жизни есть, и десктопные наверняка с 1000, а серверные - нет. В Кальке только десктопное ядро с 1000, а серверное с 300 или 250, не помню, но не 1000.

Gentoo же, видеокарта использует драйвер Radeon и в биосе ограничен, плюс крашит логин менеджеры вроде GDM, SDDM, ругаясь на кривой биос у видеокарты. Вот тут описание с файлами, где изменения

https://www.elstel.org/software/hunt-for-4K-UHD-2160p.html.en

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

Можно и так, но вдруг есть любители нарочно включать то, что должно быть выключено. Мало ли какие ситуации бывают в жизни, это просто вариант.

В бубунте кажется 1000

Кажется. 250. В росе 300.

Испытания проводил двойным слепым методом? Или поменял и сразу «заметил»?

Поменял и заметил, именно так. Это было миллиард лет назад, МНЕ разница в отклике и поведении ГУИ была очевидна, и сейчас я доказывать ничего не собираюсь. И даже более того, соглашусь что сейчас возможно разницы и нет, но проверять не буду, так как у меня всё прекрасно так как есть и трогать я это не буду больше.

Игры тут вообще не причём. Суть была в том, что изначально...

Полностью согласен и спорить не буду. Уверен что сейчас разницу в производительности и отзывчивости между этими параметрами можно увидеть только в синтетике и она будет на грани погрешности измерений.

Нет, я не поджигаю. Я просто конкретики хочу. Про NUMA - это повод, но не массовое явление. Это нужно 0.001% линуксоидов. Как и другие реальные проблемы. И каждый, кто решал такие проблемы в состоянии в двух-трёх словах описать это, но обычно доводы лоровцев на животрепещущий вопрос - «патамучо нада!»

П.с. это не наезд на тебя, а то вдруг опять не так поймёшь :)

А можно смешной вопрос? А как другие дистрибутивы ведут себя на данном компе?

Когда вообще возникает необходимость компилировать ядро кроме сборки или обновления системы из исходников?

Если нужно что-то в конфиге изменить или если какие-нибудь сторонние патчи нужны (например, сторонний планировщик CPU).

Кстати откуда вы берёте частоту таймеров? У меня ничего такого нет, ядро родное от OpenSUSE:

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# end of Timers subsystem

Прогнал тест таймеров на Linux 5.8.1, OpenSUSE, результаты нормальные, но хуже, чем у Haiku.

HPET в бивисе\уефи выключен или включён?

cat /sys/devices/system/clocksource/clocksource0

cat /sys/devices/system/clocksource/available_clocksource

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

NUMA — это довольно таки массовое явление среди линуксоидов. Не на десктопе, конечно. Собирать, конечно, никто не собирает, потому что в мейнстриме не принято обрезать нуму, на дебиане, убунте, центоси всё пучком из коробки.

numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 8 9 10 11
node 0 size: 24097 MB
node 0 free: 3715 MB
node 1 cpus: 4 5 6 7 12 13 14 15
node 1 size: 24189 MB
node 1 free: 2225 MB
node distances:
node   0   1 
  0:  10  21 
  1:  21  10 

CONFIG_HZ:

# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250

HPET в бивисе\уефи выключен или включён?

По идее включён.

что показывает?

> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
tsc hpet acpi_pm 

CONFIG_NO_HZ=y

У тебя ж оно безтиковое, откуда ты собрался брать частоту того, чего нет.

У тебя ж оно безтиковое

И это хорошо.

# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000

У тебя скорее всего этого нет потому что

CONFIG_NO_HZ=y

Как в твоей любимой haiku собсно.

Оно же не полностью безтиковое, там выше у него включена CONFIG_NO_HZ_IDLE=y.

CONFIG_NO_HZ=y

Эта опция устаревшая:

This is the old config entry that enables dynticks idle. We keep it around for a little while to enforce backward compatibility with older config files.

У меня эта опция тоже включена, но при этом CONFIG_HZ никуда не делись.

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

Нормально. Собственно старые версии логин менеджеров прекрасно работали. Просто 2560х1440 есть лишь по dvi, а менеджены нифига не могут понять какой-то выход с частотой развертки и падают, а если им этот выход указать принудительно тоже падают. Бубунта корчится с системдой часто. На Mageia вроде как есть этот патч видеокарты, но она не грузится и падает.

Ты пытаешься расжечь срач Linux vs Haiku или что? Хайку это до сих пор экспериментальная ОС, непригодная для десктопа, мало ли что у ней там с таймерами.

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

Насколько я понимаю, tsc это инструкция RDTSC и это самый эффективный и точный способ определения монотонного времени на x86. HPET используется для планирования и генерации прерываний, а не как источник времени.

У меня достаточно редкая инженерная рабочая станция от HP о двух головах. Но с приходом тредриппера в массы NUMA и на односокетных машинах уже есть. В моём случае кальковские разрабы такого железа не имеют и поэтому глубоко не вникали что там включать для NUMA. Я им уже отписал пожелание включить в их дефолтном ядре два недостающих параметра, тем более что на не NUMA архитектурах они ни на что не влияют и кушать не просят. Может они их включат в итоге, может нет, это не так важно для меня, я могу и сам это сделать.

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

Нет, не отключают. CONFIG_NO_HZ_IDLE — это уже много лет как дефолт.

man вытесняющая многозадачность. Периодические прерывания в Linux сейчас используются сугубо для переключения задач (т. н. «scheduling clock interrupts»), и когда процессор простаивает — периодические прерывания тоже останавливаются.

А именно таймеры в Linux, естественно, давно на индивидуальных прерываниях (man hrtimers). Ты серьёзно думал, что Linux в 2020 не умеет отмерять отрезки времени меньше 1 мс? :)

Ты пытаешься расжечь срач Linux vs Haiku или что?

++

CONFIG_NO_HZ == CONFIG_NO_HZ_IDLE != «безтиковое»

Ti sdelal moi ve4er

не скомпилированное можно исправить улучшить дополнить

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

Таймер прерывания использовать не умеет? В Haiku умеет.

Не толсти. Ни гайка, ни линукс всё равно никогда не будут hard realtime, а в контексте soft realtime линукс не под отзывчивость точится уже много лет.

Если на гайку навернуть вего того говна которым обмазан линукс - будет не сильно лучше.

Некоторые компании (RedHat, Suse) бэкпортирут в свои ядра определенный функционал. Для этого и нужна компиляция ядра. Но, это если говорить о крупных конторах. А, вот, рядовому пользователю уметь компилировать ядро нужно для того, чтобы указать сей навык в резюме, которое затем будет отправлено в RedHat или Suse.

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

Спасибо, мы вам перезвоним ©

Привет. Я часто вижу как ты помогаешь новичкам, причем делаешь это умело. Мне немного непонятно почему такой грамотный форумчанин как ты задает такой вопрос.

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

Кстати вы также как я помню находите время, чтобы помочь новичкам. Огромное спасибо вам.

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

Давай я тебе конкретику скажу - например, вышло на днях ядро 5.4.60, и ты хочешь накатить патчи для работы ядра под каким-нить WSL2, или vmware (при этом убрав из ядро всё, вообще, всё лишнее, заточив под виртуализацию), берёшь конфиг от какого-нить Alpine Linux Virt, или Void и собираешь за 2-3 минуты лёгкое ядро

Потому что не все доступно в виде модулей.

Зачем компилировать ядро?

Вот тут можно спросить: Сборка ядра без 99% драйверов (комментарий)