MuQSS, liquorix и ренессанс linux десктопа

прохладная история, но у меня и на стоковом ядре описанных проблем нет даже на старом проце

Прикольно, надо будет поставить, попробовать, спасибо.

Без твоего железа несчитово, может у тебя затычка вместо проца.

Перепробовал тогда всё: приоритеты, cgroups, тюнинг CFQ, пересборка debian stable без tickless и с 1000hz.

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

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

А это тоже не работает.
Браузер и всё остальное то всё равно по ядрам будет скакать, если не прибить гвоздями тоже.

Вспомнил, с чего всё вообще началось то пару лет назад: у меня неделями пахал SASPlanet, собирая кэш, и пресекал на корню любые попытки поиграть в l4d.
Ему где-то тогда под вайном процентов 40% одного ядра надо было (сейчас меньше), но превращал в слайдшоу любую игру, пока не пошлёшь SIGSTOP.

Давно не игрался уже, но l4d всё ещё стоит.
Запустил чтение из /dev/urandom, пострелял пару минут зомбей. Без проблем.
Никакие приоритеты не трогал, из коробки функционирует как надо.

Всё-таки что-то конкретно не так с CFQ.
Жаль Линус противится альтернативным планировщикам.

Оформи в новость. Не все посетители ЛОРа ходят на форум.

MuQSS хорош, у меня с ним некоторые игры под Wine гораздо лучше работают чем на стандартном CFS.

Долгоиграющий многопоточный пожиратель cpu с nice 19 не то чтобы совсем уж незаметен, но доставляет меньше проблем.

Кстати, MuQSS еще и SCHED_IDLEPRIO поддерживает, с таким приоритетом компиляцию в фоне ты вообще не заметишь.

schedtool -D -e make -jX

А для высокоприоритетных процессов есть SCHED_ISO - аналог реалтайма, но не требующий специальных полномочий. Я на X сервер выставляю этот SCHED_ISO, это помогает от тормозов курсора мыши в сценариях, когда очень много процессов одновременно грузят проц на 100%.

Например при запуске:

stress -c 32

На X сервере без SCHED_ISO курсор начинает фризится на несколько секунд, а с SCHED_ISO работает нормально. nice -20 в таких случаях не спасает совсем.

Кто знает где скачать патч MuQSS не для первого выпуска 5.4 от 2019 года, а применимого к текущей версии этой ветки?

Можно отсюда взять. Правда, там не отдельно MuQSS, а весь патчсет ck.

Без твоего железа несчитово, может у тебя затычка вместо проца.

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

у меня с этим tkg вообще ужасный опыт, видимо делалось под 16 ядерные процессоры чтобы яшиенку пожарить… на стоке в игрушках все плавно (ну как плавно, как wine/dxvk на моем железе вытягивает так и идет), а с tkg одни лаги, 4 ядра, загрузка процессора 30% максимум.

MuQSS хорош, у меня с ним некоторые игры под Wine гораздо лучше работают чем на стандартном CFS.

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

Наверное интересно было бы посмотреть на то же самое, но с одним потоком стресс-теста. В формате как без ренайса, так и с 19.
Возможно выйдет показательный бенчмарк, как плохеет стандартному планировщику.

Странную штуку вы описываете. На двухядерном амд у меня компиляция генту с фоновым свопингом никак не отражалась на интерфейсе, в стоковом дебиане на пеньтиум дуо до 2-3 потоков на ядро нагрузки не видно. Может это уникальная проблема композитора? Или конкретной линейки цпу?

Да что не так с этими современными дистрибутивами/цпу/ядрами?! Всё та же старая страшная RPi3, 900Мгц, тротлинг по просадке напряжения, дебиан8, kwin4/xfce. cgrops для цпу активирован, ядро самосборное 4.4-raspberry-pi-sorces, режим «сервер», таймер 100Гц.

Ну запустил я stress -c 32, ну стал файерфокс еле ворочаться и даже htop запускался 4 секунды на горячую и полсекунды отрисовывал список. Но вот на отзывчивости курсора Х-сервера это точно никак не сказалось.

На X сервере без SCHED_ISO курсор начинает фризится на несколько секунд, а с SCHED_ISO работает нормально. nice -20 в таких случаях не спасает совсем.

Хм. У меня на i7-2600 эффект от «stress -c 32» разве что в играх заметен, на десктопе, в браузере и при просмотре видео все ок.

ну у меня новый проц/ядро, херни как у тс не наблюдаю. это новые вещества у тс походу

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

Так это же не универсальная команда для всех процессоров. У меня проц 4 поточный. Запусти:

stress -c 1024

Или сам найди значение, при котором у тебя курсор будет время от времени тормозить.

К тому же я это на MuQSS проверял, на CFS может потребоваться большее/меньшее значение, так как он иначе работает.

И понятно, что это синтетика, в реальности маловероятно, что будет такая ситуация.

Нет, память у меня не кончается, у меня ее 16 GB и около 90% свободно во время работы этого stress.

Есть также шанс, что на CFS это вообще не сработает ни при каком значении и что это чисто проблема MuQSS.

Или сам найди значение, при котором у тебя курсор будет время от времени тормозить.

Хм, с 1024 тоже никакого эффекта. Ну, кроме просаживания фпс в играх - загрузка проца > 900.

Ядро со стандартным конфигом gentoo-kernel (вроде из федоры конфиг берут). Nice не трогал. Видимо с CFS такой проблемы нет.

MuQSS, древний i3-2120, тормозов курсора ни при stress -c 32, ни при stress -c 1024 не заметно. Разве что команды в терминале работают с толкача. Может как-то влиять вяленый?

$ stress -c 1024 &
[1] 5621
stress: info: [5621] dispatching hogs: 1024 cpu, 0 io, 0 vm, 0 hdd
$ ps aux | grep stress
user       5621  0.0  0.0   3656  1860 pts/1    S    09:03   0:00 stress -c 1024
user       5624  0.4  0.0   3656    96 pts/1    R    09:03   0:00 stress -c 1024
user       5625  0.3  0.0   3656    96 pts/1    R    09:03   0:00 stress -c 1024
$ inxi -c
CPU: Dual Core Intel Core i3-2120 (-MT MCP-) speed/min/max: 1608/1600/3300 MHz Kernel: 5.10.9-zen1-1-zen x86_64 Up: 59m 
Mem: 3665.1/5901.8 MiB (62.1%) Storage: 763.85 GiB (28.4% used) Procs: 182 Shell: Bash inxi: 3.2.02...

Может как-то влиять вяленый?

Конечно, и влияет. Я только на X это проверял.

А что насчет куда больших значений, например, 10 тысяч или 20 тысяч?

И уточню, что я это проверял на двух процессорах, которые у меня имеются: это Celeron N2840 и Pentium G4620.

А что насчет куда больших значений, например, 10 тысяч или 20 тысяч?

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

Что касается плавного скроллинга. Я помню, что, когда в Windows это давно сделали, в Linux скроллинг по-прежнему был не плавным. Однако, спустя много лет, в Linux сделали тоже. И он стал тормозить компьютер.

Причина в том, что в Windows для этого используется аппаратное ускорение, а в Linux - нет. Не знаю почему, и что мешает сделать.

По поводу микрофризов. Да, они раздражают. Я их уже даже не замечаю. Работает-работает, через 2 минуты всё остановилось на очень маленькое время, потом снова продолжилось. Я не знаю почему так. Может это последствия отмены глобальной блокировки дают о себе знать.

Кстати, пользователи Wayland заявляют, что обеих проблем у них нет.

Кстати. Отключаем Smooth Scrolling в Firefox. Теперь скроллом мыши скроллинг не плавный. А клавишами-стрелочками клавиатуры - плавный. То есть, плавный скроллинг не отключается на самом деле.

Понятно. Ну, значит либо CFS не подвержен, либо в конфиге ядра что-то помимо шедулера может влиять на это, либо вообще у меня железо какое-то странное (во что я не верю, конечно, но кто знает). У меня конфиг от арчевского ядра.

Это на какой версии FF? У меня в FF 84 скроллинг стрелочками не плавный.

Я только что проверил - скроллинг клавишами тоже стал не плавный. Значит я написал неправду. Извиняюсь.

Вспомнил. В тот раз я не знал, что плавный скроллинг отключается в настройках. И отключил его параметром в about:config. В итоге отключился только плавный скроллинг мышью, но не клавишами.

Да, на винде приоритеты и свопинг, к сожалению, лучше. А плавную прокрутку в браузерах лучше отключить.

Исключение XP: она сбрасывает в своп при сворачивании окон.

По поводу микрофризов. Да, они раздражают. Я их уже даже не замечаю. Работает-работает, через 2 минуты всё остановилось на очень маленькое время, потом снова продолжилось.

Помню такая проблема была на определенных версиях Opera Presto под виндой, очень раздражало. Потом исправили все-таки. Но у меня тогда был древний однопоточный Celeron на 2.2 или 2.4 ГГц из семейства Pentium 4. При том, я им умудрялся даже AVC DVD рипы делать и выкладывать на рутрекере. Это сейчас народ с жиру бесится.

Но вот на отзывчивости курсора Х-сервера это точно никак не сказалось.

Я разве хоть что-то про курсор говорил?
У меня и на стоковом ядре с ним проблем нет.

Да это он на мое сообщение отвечал, судя по всему.

Ну, значит либо CFS не подвержен, либо в конфиге ядра что-то помимо шедулера может влиять на это, либо вообще у меня железо какое-то странное (во что я не верю, конечно, но кто знает).

Я с необычными проблемами от нагрузки на процессор под линукс вообще не сталкивался. А вот посмотреть видео с одновременной работой торрентов не всегда получается нормально. 50+ МБ/сек и при просмотре какого-нибудь fullhd звук и видео иногда подвисают.

А вот посмотреть видео с одновременной работой торрентов не всегда получается нормально. 50+ МБ/сек и при просмотре какого-нибудь fullhd звук и видео иногда подвисают.

У меня тоже такое бывает, но не от торрент-клиента (у меня банально скорость интернета не позволит сильно загрузить HDD), но вот если что-то большое копировать в пределах HDD, то видео начинает заикаться и некоторые программы с задержкой открываются. В качестве I/O шедулера у меня BFQ выбран, но я также пробовал и mq-deadline, разницы особо нет в этом плане.

У меня на винде 7 вот такое было Ужасные приоритеты диска.
До сих пор не знаю кто был виновник, может быть SSD. У меня того компа уже нет. Но в ту пору я ставил еще openSUSE 12.1 x64 KDE4, не помню в ней таких проблем.

Теоретически, если бесконечно наращивать нагрузку, то рано или поздно абсолютно что угодно начнёт физиться. Альтернатива это только вручную выделять ядра под определённые задачи.

Это понятно, но все равно неприятно же, особенно когда дело касается курсора мыши. Впрочем, как я уже сказал, SCHED_ISO на процессе X сервера мне помогает от тормозов курсора.

Мы ведь говорим о микрофризах интерактивных задач? В моём случае движение курсора мыши это такая интерактивная задача, которая берёт на себя 10% одного из 4 ядер и считается полностью на цпу.

Строго говоря да, мой пример некорректен потому что stress -c 32 должен был оставить под неё 12,5% при 10% требуемых.

Но курсор остаётся идеально отзывчивым даже при -c 128, хотя остальные приложения практически умирают, например htop тратит больше 3 секунд на одно обновление экрана. Как раз в этом не вижу ничего удивительного, ведь приоритеты у них строго равные, а делить сказано поровну. На фоне этого непонятно скорее другое, кто и как обеспечивает Х-серверу подавляюще высокий приоритет по выделению цпу.

На фоне этого непонятно скорее другое, кто и как обеспечивает Х-серверу подавляюще высокий приоритет по выделению цпу.

Может быть, /proc/sys/kernel/sched_autogroup_enabled влияет на это? У меня отключен, но его вручную отключаю через sysctl (а на MuQSS его попросту нет). А так он в большинстве дистрибутвов по умолчанию включен, насколько я знаю.

Ради эксперимента, кто-нибудь попробуйте отключить этот autogroup и запустить тот же stress.

З.Ы. при этом механизм nice работает. При 19 htop становится ещё более мёртвым, а вот -20 возвращает ему почти нормальную отзывчивость.

У меня включен.

Как это работает и откуда он знает, что надо именно xorg, kwin и konsole поднимать?

Ради эксперимента, кто-нибудь попробуйте отключить этот autogroup и запустить тот же stress.

Попробовал, с -с 64. курсор нормально, а вот htop за 2 минуты не обновил ни одного кадра. А после снятия stress глючил. А вот вкладки konsole переключались резво.

Как это работает и откуда он знает, что надо именно xorg, kwin и konsole поднимать?

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

Если я все правильно понял, если stress и Xorg в разных группах, то stress просто не может весь проц загрузить.

Это cgrops так поступает, и то при дефолтной настройке через systemd и если stress и х-сервер запущены в разных сеансах. И то, настройка задана на общее время выполнения, а тут явно подкручено что то такое, что Хорг не падает в конец в общей очереди, а получает доступ к цпу вне очереди без задержек. Иначе свою долю он бы получал, но с заметными фризами.

З.Ы. При -с 512 никакого влияния на курсор, никакого влияния на переключение в vt, и там, от рута, htop даже не дёргается. Но вот в графике kwin полностью выключился из работы и отказался переключать окна. konsole при этом нормально приняла Ctrl+C. Дальше гнать потоки не стал, лимиты на порождение потоков не резиновые да и память стала заметно подскакивать.

Интересно. И всё-таки, что за железо, если не секрет?
У самого порой чешется попробовать этот liquorix, но…на FX8120 у меня могло подтормаживать видео/прокрутка при долгой сборке с -j8
на новом ryzen 3100 - незаметно абсолютно.