LINUX.ORG.RU

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

 , ,


3

4

Год или два назад, хотел решить проблему дёрганного UI в linux.
Проявлений у неё много, но простейший кейс, это однопоточный процесс, заставляющий дёргаться всё остальное на четырёхядерном железе.
Микрофризы на разных программах разной силы. Скажем, chromium более чувствителен, чем firefix. Но даже в emacs они порой ощутимы.
Перепробовал тогда всё: приоритеты, cgroups, тюнинг CFQ, пересборка debian stable без tickless и с 1000hz.

Всё впустую. И в сумме, и по отдельности.
Да, cgroups вполне успешно душит общее использование CPU низкоприоритетной группой, но когда надо поскроллить в хромиуме, в группе гораздо с гораздо более высокими cpus shares, лаги никуда не деваются.

Не люблю наколенные поделки, но раз в прошлом ничего не получилось, попробовал стороннее ядро http://https://liquorix.net
Честно говоря, немного шокирован результатами. Моя конфигурация cgroups там не работает, только скрипт повышающий приоритет декстоп-ориентированым процессам, но на этом с ара-тюнингом с моей стороны всё.

Так вот: я вообще не могу навскидку понять, завершилась моя фоновая однопоточная числодробилка, или нет.
Другой типичный юзкейс: проявка raw в rawtherapee, пока в picture-in-picture фаерфокс играет что-то с ютуба.
На стоковом ядре, или из бекпортов, видео жёстко лагало и периодически просто фризилось на несколько секунд, понижение приоритета rawtherapee не помогало.
С ядром liquorix и rawtherapee с nice 10 вижу, как периодически выпадают кадры из видео, когда rawtherapee пытается всё процессорное время сожрать, но общая плавность вполне сохраняется.
nice начинает наконец реально работать с точки зрения отзывчивости. Долгоиграющий многопоточный пожиратель cpu с nice 19 не то чтобы совсем уж незаметен, но доставляет меньше проблем.

Из совсем неожиданных эффектов: очень быстро переключаются рабочие столы. Редко что-то завершаю, от того у меня полно программ и окон, и почему-то на стоковом ядре, даже без нагрузки, нужно немного времени чтобы всё нарисовать.
Казалось, это норма. Оказывается нет.

Сижу с этим ядром на одной из машин уже месяц, пока проблем не было.
Работают ли числодробилки медленнее? Не знаю. Я бы не огорчился и от 20% пенальти по общему runtime.
Из нехорошего: там ещё кучи каких-то патчей, решающих проблемы, которых у меня нет. Стрёмненько.
Ядра пекутся как пирожки, а не раз в вечность. Тоже стрёмненько.
Нет поддержки x86.
Пока из недостатков вроде всё.

TL;DR: MuQSS делает всё, о чём мы мечтали, и без ручного тюнинга.

★★★★★

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

anonymous
()

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

fernandos ★★★
()

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

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

torvn77 ★★★★★
()

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

anonymous
()
Ответ на: комментарий от torvn77

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

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

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

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

aidaho ★★★★★
() автор топика
Последнее исправление: aidaho (всего исправлений: 1)
Ответ на: комментарий от aidaho

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

anonymous
()

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 в таких случаях не спасает совсем.

Kron4ek ★★★★★
()
Последнее исправление: Kron4ek (всего исправлений: 2)

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

tamo
()
Ответ на: комментарий от kakaxa

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

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

bhfq ★★★★★
()
Ответ на: комментарий от Kron4ek

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

bhfq ★★★★★
()
Последнее исправление: bhfq (всего исправлений: 1)
Ответ на: комментарий от Kron4ek

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

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

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

aidaho ★★★★★
() автор топика

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

kirill_rrr ★★★★★
()

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

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

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от Kron4ek

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

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

altwazar ★★★★
()
Ответ на: комментарий от kirill_rrr

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

anonymous
()
Ответ на: комментарий от Kron4ek

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

anonymous
()
Ответ на: комментарий от altwazar

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

stress -c 1024

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

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

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

Kron4ek ★★★★★
()
Последнее исправление: Kron4ek (всего исправлений: 3)
Ответ на: комментарий от anonymous

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

Kron4ek ★★★★★
()
Ответ на: комментарий от Kron4ek

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

Kron4ek ★★★★★
()
Ответ на: комментарий от Kron4ek

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

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

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

altwazar ★★★★
()
Последнее исправление: altwazar (всего исправлений: 4)
Ответ на: комментарий от Kron4ek

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...
anonymous
()
Ответ на: комментарий от Kron4ek

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

Kron4ek ★★★★★
()
Последнее исправление: Kron4ek (всего исправлений: 1)
Ответ на: комментарий от Kron4ek

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

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

altwazar ★★★★
()

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

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

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

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

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

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

ZenitharChampion ★★★★★
()
Ответ на: комментарий от altwazar

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

Kron4ek ★★★★★
()
Ответ на: комментарий от Kron4ek

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

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

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

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

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

Hungarian-Deniska
()
Ответ на: комментарий от kirill_rrr

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

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

aidaho ★★★★★
() автор топика
Ответ на: комментарий от aidaho

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

Kron4ek ★★★★★
()
Ответ на: комментарий от Kron4ek

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

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

altwazar ★★★★
()
Последнее исправление: altwazar (всего исправлений: 1)
Ответ на: комментарий от altwazar

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

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

Kron4ek ★★★★★
()
Последнее исправление: Kron4ek (всего исправлений: 1)
Ответ на: комментарий от Kron4ek

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

Hungarian-Deniska
()
Ответ на: комментарий от Kron4ek

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

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

Kron4ek ★★★★★
()
Ответ на: комментарий от aidaho

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

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

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

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

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

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

Kron4ek ★★★★★
()
Последнее исправление: Kron4ek (всего исправлений: 1)
Ответ на: комментарий от aidaho

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от Kron4ek

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

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

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

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

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

Kron4ek ★★★★★
()
Последнее исправление: Kron4ek (всего исправлений: 3)
Ответ на: комментарий от Kron4ek

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

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

kirill_rrr ★★★★★
()

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

kott ★★★★★
()
Последнее исправление: kott (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.