И ещё раз, зачем Вам ядро пересобирать, тем более RT?

Ядро пересобирать для опыта и под своё железо. Читал, при сборке под железо производительность возрастает. Под RT собирать - было изначальной задачей. Пользуюсь Guitar Rig 6 (через carla или wine). Получаю задержку на вход. Размер буфера не регулируется. Искал wine-rt - вылез на информацию в духе "Linux не нуждается в wine-rt так как имеет своё RT ядро.", а дальше пошло-поехало.

Прошу прощения за скрин.

ну гугл знает о Вашем баге, фикса не знает, но собирать руками ядро -- плохая идея, поставьте готовое.

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

без хороших навыков программирования -- плохая идея, можно не заметить критичный ворнинг и потом ловить баги, rt-ядро скорее всего уже есть готовое, зачем изобретать велосипед с квадратными колёсами?

Хотелось бы ещё оптимизировать конфиг под своё железо.

каким образом? и что именно? не хочу Вас расстраивать, но с 99% эффект будет обратным, да, я надеюсь Вы понимаете, что RT ядро существенно снижает производительность?

Вот про это - неправда? По поводу прибавки производительности в форме 30 кадров/сек?

Почему снижает производительность?

ну так почитайте, что такое RT ядро, блин....

откуда такой пессимизм в адрес самосборных ядер? :) я не особо компетентен, но даже "пальцем в небо" первым в голову приходит выбор семейства проца. в отличие от generic, тут есть шанс, что будут задействованы дополнительные процессорные инструкции, которые, авось, и ускорят чего. пусть даже на 1%. ну и, далее, можно попутно отключить кучу неиспользуемых дров под чужое железо, сделать их модулями и т.д. rt-ядро не защищаю, я его не юзал и не интересовался.

Давно так не гоготал, спасибо

ну так почитайте, я очень долго сидел на freebsd, и там есть очень хорошие статьи по поводу сборки ядер, ну и для Freebsd это штатная операция, в отличие от Linux. так вот использование доп. фич. проца в ядре как правило ведёт к негативным эффектам, ну, собственно гугл никто не отменял.

загуглил из интереса "why self compiled kernel is bad", что-то пока даже не могу найти явных аргументов против :) замечу, я не оспаривал утверждение "это не принесёт особо много пользы". я оспаривал "эффект будет обратным" (в контексте оптимизации под железо)

> использование доп. фич. проца в ядре как правило ведёт к негативным эффектам А этот момент можно как-то подробнее осветить? Уж больно интересно стало

Ну там много факторов, сейчас не нахожу где это было, но чуть ли не в хэндбуке, суть сводилась к тому, что резко возрастает объём бинарного кода, и на это накладываются ограничения на вызов прерываний, в общем, достаточно убедительно было, что компилировать ядро надо с --no-mmx --no-sse и --no-sse2

От векторизации увеличивается объём бинарного кода? Звучит как ересь, если честно. Чем рисовать циклы через метки+jmp — лучше воспользоваться несколькими векторными инструкциями, не? А хендбук — не истина в последней инстанции, его пишут люди и людям свойственно ошибаться

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

ну если вдруг когда-нибудь найдёшь — приходи, почитаем

> 20 лет назад забыть нахуй

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

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

интересно будет посмотреть подвержены ли новые generic-и таким приколам надеюсь, нет

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

ядрозависимого СОФТА я что-то вообще не помню

например - некоторые версии ядра ломали доступ к ресурсам на MS DFS...