xanmod... рвет linux-rt в low-latency аудио задачах???

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

Конечно внесёт. Но альтернативные подходы к профилированию с меньшими накладными затратами сложнее, а картинку оно всё равно может дать, точнее 100% даст при правильно подобранной нагрузке и частоте сэмплирования.

Если ты не против я поправлю немного теги, чтобы больше народу подтянуть.

Ага, спасибо

Так приоритеты процессов же разные.

Остальные всё равно планируются и выполняются, по идее, наверно, приоритет, видимо влияет на то, какой квант времени выделяется на процесс, не могут же остальные не выполняться совсем, Где-то у таненбаума была формула, по которой рассчитывалось, сколько процессов может быть выполнено, как rt на процессоре, я точно не знаю, Вообще-то, как работает планировщик, но он не может полностью защимить другие процессы, по идее

приоритет, видимо влияет на то, какой квант времени выделяется на процесс

100% притом относительно количества процессов которые ещё планируются на этом ядре. По-крайней мере, пока политика планирования RT_PREEMPTIVE, с RT_FIFO уже по-другому дела обстоят немного.

Этот товарищ всякие системные штуки регулярненько велосипедит, он лучше моего погадает :)

Да, сейчас сделаю.

Справедливости для perf даже на высоких частотах может показывать cpu bound проблемы с точностью до единиц микросекунд. Но с вводом выводом всё как всегда сложнее конечно.

Вот это конфиг xanmod

https://pastebin.com/U7xj6ZQa

что об этом думает post-factum? Почему xanmod порвал rt?

с чем сравнивать?

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

Погоди, сейчас все будет. У меня тут затыки, не могу с мобилы файл на линукс скинуть (не связанный с сабжем), бешусь пока.

Вот linux_rt

https://pastebin.com/qGgS7nCB

бросается в глаза это

# CONFIG_PREEMPT is not set

не знаю, имеет ли это значение, если ядро и так рт.

BTW, есть ли разница между рт и обычным ядром дистрибутива?

бросается в глаза это

Ну так вместо этого ж стоит CONFIG_PREEMPT_RT=y

нужен Kron4ek

BTW, есть ли разница между рт и обычным ядром дистрибутива?

Есть, на обычном более-менее работает только с задержкой 5,3 мс. Так практически стабильно. 2,6 мс - практически не работает.

Дифф на 4к строчек :)

чтобы два раза не ходить сделай так:

diff -U 1 rt.conf xanmod.conf > config.diff

Вот дифф:

https://pastebin.com/WTc2dpfT

Предположу, что CPU шедулер решает. Помимо некоторых отличий в конфиге и прочих патчей, в xanmod еще и другой шедулер TT (Task Type).

Ради эксперимента можно попробовать собрать ванильное ядро чисто с TT шедулером и посмотреть, какая задержка будет. Ну и герцовку таймера на 500 Hz поставить тоже.

я правльно понимаю, что это на встройке, а не юсб интерфейсе? и какое железо?

Я бы поэксперементировал ещё с CONFIG_HZ_500/1000.

Ещё интересно как понимать PREEMPT_DYNAMIC.

Ещё, есть подозрение что anmod ядрышко собрано с lto и если бинарь драйвера не блоб, те же 20-30 процентов разницы легко могут оказаться там.

Ещё интересно как понимать PREEMPT_DYNAMIC.

Это для переключения режима preemption (между none, voluntary и full) через параметры ядра. То есть раньше можно было только через конфиг во время компиляции менять, а теперь с PREEMPT_DYNAMIC можно через параметры ядра. Например:

preempt=full

Ещё, есть подозрение что anmod ядрышко собрано с lto и если бинарь драйвера не блоб, те же 20-30 процентов разницы легко могут оказаться там.

Точно нет, иначе бы в конфиге была включена одна из опций: LTO_CLANG_FULL или LTO_CLANG_THIN.

А, да, там только SUPPORTS

xanmod

Что это и почему я должен знать?

Да, на встройке.

Железо - Realtek ALC272, ноут на SandyBridge. Проц древний core i3.

Везде DAW монопольно захватывает, ЕМНИП.

Щас запустил Sonar сквозь ASIO на десяточке, ютуба в лисе как гавкала, так и гавкает.

Платформа - Sandy Bridge

и дискретка тех же годов. У моего такое же... почтенное всё.

NixOS и в нем ядро xanmod 5.14

glxgears точно работает через шмеля

Ну, что... Попробовал на Ubuntu 20.04 с дровами 390.

~$ uname -r
5.15.11-xanmod1-tt

и немедленно решил проверить не только Шмеля, но и OpenCL, за коим, собственно, Шмель лично моему старикашке и нужен.

~$ optirun darktable -d opencl
[  120.103368] [ERROR]The Bumblebee daemon has not been started yet or the socket path /var/run/bumblebee.socket was incorrect.
[  120.103399] [ERROR]Could not connect to bumblebee daemon - is it running?

~$ systemctl status bumblebeed.service
● bumblebeed.service - Bumblebee C Daemon
     Loaded: loaded (/lib/systemd/system/bumblebeed.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Sat 2021-12-25 20:04:55 +04; 8s ago
    Process: 2064 ExecStart=/usr/sbin/bumblebeed (code=exited, status=1/FAILURE)
   Main PID: 2064 (code=exited, status=1/FAILURE)

Так-то. Жаль, конечно. Но фиг с ним.

~$ uname -r
5.4.0-91-lowlatency

~$ systemctl status bumblebeed.service
● bumblebeed.service - Bumblebee C Daemon
     Loaded: loaded (/lib/systemd/system/bumblebeed.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-12-25 20:23:49 +04; 28s ago
   Main PID: 742 (bumblebeed)
      Tasks: 1 (limit: 14207)
     Memory: 1.4M
     CGroup: /system.slice/bumblebeed.service
             └─742 /usr/sbin/bumblebeed

дек 25 20:23:49 RockseR systemd[1]: Started Bumblebee C Daemon.
дек 25 20:23:49 RockseR bumblebeed[742]: [    5.675049] [INFO]/usr/sbin/bumblebeed 3.2.1 started

Попробовал на Ubuntu 20.04 с дровами 390

А ты уверен вообще что у тебя дрова 390 установлены корректно и собраны под xanmod ядро? Откуда в Ubuntu 20.04 патч на nvidia-390 под ядро 5.15? На 99% у тебя тупо модуль ядра nvidia не собирается через dkms. Исходники nvidia драйвера нужно патчить под новые ядра.

ы уверен вообще что у тебя дрова 390 установлены корректно

Да, насколько это вообще возможно.

и собраны под xanmod ядро?

Абсолютно уверен, что собраны они не под XanMod, а под 5.4 те ядра, что есть в репах, которые подпатчены по соображениям Каноникл, и под которые собрано всё, из чего сделана Убунта.

На 99% у тебя тупо модуль ядра nvidia не собирается через dkms.

Не на 99, а на 100. :D

Однако,

В Ubuntu 20.04 ядро 5.4. С XanMod 5.4 работает всё, включая OpenCL на дискретной карте.

С XanMod 5.10 и 5.13 работает всё, исключая OpenCL.

Драйвер nvidia-390, Ubuntu 20.04, ядра 5.10, 5.13, OpenCL

так что, сдается мне, дело не в наборе патчей (XanMod-фиганмод, Каноникл-фигоникл), а в том, с какими версиями ядер работают 390 из каноникловских реп. А с какими не работают. А с какими одно работает, а другое - нет.

ЗЫ. Вкорячивал как-то в Убунту дрова с сайта nvidia. Теперь боязно, ну его, у меня сейчас всего один ноутбук.

с какими версиями ядер работают 390 из каноникловских реп. А с какими не работают

Конечно. И не будет работать - надо патчить драйвер nvidia. С сайта nvidia тоже работать не будет - все равно патчить надо.

В нормальных дистрибутивах типа Arch есть патчи под последние ядра, там все работает.

На NixOS сейчас я брал патч от Арча (благо пропатчить пакет на NixOS тривиально).

А я вчера компилял-компилял, да не выкомпилял. Свап съёло, память съело, всё зависло... Да и вообще, что-то полюбил мой комп утекать непойми куда. Смотрю по показателям памяти, все программы в пределах разумного, вроде есть свободная память (всего 8гигов) но свап забит (всего один гиг) и комп люто тормозит. От чего это? Новые сособы работы с видеопамятью в ядре дают о себе знать? Или новые движки файрфокса? Как узнать кто сидит в свопе и почему?

Ну здрасьте, приехали. Сто раз обсуждали ж уже.

1. swap on zram only, disksize=1.5*MemTotal (то есть можно 12 гиг)
2. nohang или earlyoom демон
3. oom-sort из пакета nohang - проверять кто сидит в свопе.
4. высокий swappiness или le9 patch на ядро.

всего 8гигов

С такими объемами можно хром собирать без тормозов.

см также Просто оставлю это здесь: Игра в supertux2 с множественными `tail /dev/zero` в фоне без зависаний

см также https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/

делайте как у меня: zram disksize = 4 * MemTotal. No responsiveness issues: https://www.youtube.com/watch?v=1uhcZwuvXLI (with le9).

Это здорово, конечно, я помню наши разговоры, но ломать систему и сильно кастомизировать её не хочется, потому что сиди потом, вспоминай. Не так давно появился systemd-swap, теперь он уже устаревший. Завтра zswap отвалится и опять начинай сначала. Сейчас временами мне это совершенно не мешает заниматься ни чем, тритыщимильён приложений и всё работает, а временами прям невозможно, запустил браузер, всё зависло.

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

но ломать систему

Так она сейчас сломана, а вы ее как раз вылечите.

Поставил сейчас собирать ядро

Какое ядро? С какими патчами?

Обсуждаемое, xanmod.

не забудьте проверить или поправить значения ручек: vm.anon_min_kbytes, vm.clean_min_kbytes, vm.clean_low_kbytes.

zram+xanmod способны дать хорошую отзывчивость при нехватке памяти при правильных настройках.

А в других ОС типа как-то иначе? Везде DAW монопольно захватывает, ЕМНИП. В линуксе как раз с этим лучше.

Час назад играл через конвольвер в cakewalk, параллельно слушал ютуб в браузере.
Если два ASIO-приложения запустить, думаю, тоже работать будет, если каждому свои каналы отдать. Но надо пробовать. Венда.

hakavlad Kron4ek pon4ik

Чудеса ещё чудесатее!

Эффект есть только при работе через pipewire!

Если запустить Ardour на голой alsa, то все сыпется, на 48000/64 вообще не работает!

Это странно само по себе, обычно на чистой alsa стабильнее с более низкой задержкой.

А может как-то это xanmod ядро знает про pioewire и специально его как-то приоритетные шедулит?

Пробовал запускать pipewire и с rtkit модулем и без. Эффект есть в обоих случаях.

performance

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

ядро знает про

Посмотри приоритеты. Для реалтайма их вручную выставляют.

Посмотрел, вроде и влияние есть, но как-то не до конца понятное.

У pipewire высокий приоритет, но не максимальный. Снижение приводит к xrun’ам, но все равно не таким сильным как у ardour на голой alsa. Повышение до максимума и выбор FIFO планировщика чуть-чуть улучшает работу на 96000/64, но не делает идеальной.

R_He_Po6oT скажи что я не схожу с ума…

АААААААААааааааа!!!!

Обычное ядро от NixOS, вообще не PREEMPT, версии 5.15 - работает еще лучше! С такой же низкой задержкой как xanmod, но еще стабильнее! Что вообще происходит???

linux-rt 5.10 от NixOS работает намного хуже.

Одно из двух - либо в последних ядрах что-то подкрутили и они теперь low latency, либо в NixOS что-то подкрутили.

Сейчас проверю в своем LFS на ванильном 5.14 (скачано с kernel.org и только le9 патч наложен).

Проверил - вообще все плохо… Конфиг ядра от Арча взят. Я нихрена не понимаю…

Получается в арче как-то не так ядро собирают???

Сейчас проверю в своем LFS

Ты используешь LFS в качестве рабочей системы? Однако...

Обычное ядро от NixOS, вообще не PREEMPT, версии 5.15 - работает еще лучше!

Там же вроде PREEMPT_VOLUNTARY включен, или я ошибаюсь? А в Арчевском конфиге полный PREEMPT. Можешь попробовать на своем ванильном 5.14 тоже на voluntary переключиться, добавив в параметры запуска ядра:

preempt=voluntary

Возможно еще, что в 5.15 что-то наулучшали, так что стоит попробовать 5.15 с Арчевским конфигом.

В арче 300 HZ тик шедулера.