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

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

Если как следует изучить опции утилиты ps то достаточно просто придумать скрипт на баше который в зависимости от имени процесса(case all)) будет сажать его на то или иное ядро за одно выкидывая все неизвестные процессы с тех или иных избранных ядер.

Intel Core i5-7500T

le9 patch не тестировал?

The attached kernel patch (applied on top of 4.18.5) that I’ve tried, almost completely eliminates the disk thrashing(the constant reading of executable(and .so) files on every context switch) associated with freezing the OS

Не пробовал. Судя по его описанию, он уменьшает этот disk thrashing в ситуациях с нехваткой памяти, так что вряд ли мне поможет.

вряд ли мне поможет

А в чем нужна помощь?

Автогруппы включены в Ubuntu и Fedora, выключены в Debian.

С автогруппами какой угодно стресс не должен влиять на другие группы - ведь цп делится между группами, а не между процессами.

Таким образом, при включенных автогруппах stress -c 32 и stress -c 1000 одинаково влияют на Xorg.

скрипт на баше который в зависимости от имени процесса

https://github.com/Nefelim4ag/Ananicy

В том, чтобы во время массивного I/O на HDD процессы, которые тоже к HDD обращаются, не заикались. Может быть, ionice поможет.

ionice не работает т.к. не управляет background writeback. вообще с тормозным механическим диском тебе никакие припарки не помогут. меняй на ssd и/или разноси нагрузку по разным дискам

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

активных грузящих потоков запускают ровно по количеству аппаратных потоков у проца

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

это херня полная, никто 128активных потоков не запускает, если столько аппаратно у проца нет

SSD - штука хорошая, я планирую купить. Однако странно, что все так плохо на HDD даже с BFQ, который по описанию должен с этим помогать:

Regardless of the actual background workload, BFQ guarantees that, for interactive tasks, the storage device is virtually as responsive as if it was idle. For example, even if one or more of the following background workloads are being executed:

Но нифига. По моему опыту, что bfq, что mq-deadline в таких ситуациях примерно одинаково работают. И там, и там все тупит и заикается. И раньше с CFQ примерно так же было.

Проц какой?

никто 128активных потоков не запускает

Правильно, запускают nproc, а далее процессы еще разветвляются, и получаем nproc*10.

по нормальному делают пул потоков, с количеством одновременно активных == количеству аппаратных. разветвляется только у говноделов

нет никакого смысла нагружать например 4поточный проц активными 32потоками нагрузки

В реальных задачах может быть куча потоков. Вон лиса 8 потоков включает по умолчанию. У хрома и того больше. Это для примера.

все эти потоки спят 90% времени, активных меньше чем аппаратных

никто 128активных потоков не запускает

Я запускаю не меньше 500 обычно: https://www.youtube.com/watch?v=nSCT_zZHYYQ

зачем? это видео от местного регистранта со стресс-тестом, так что ты клоун

С автогруппами какой угодно стресс не должен влиять на другие группы - ведь цп делится между группами, а не между процессами.

Выше писал, что пытался решать проблемы отзывчивости с помощью cgroups.
Это не работает, потому что планировщик по прежнему проблемный (с точки зрения реакции UI).
Загружаешься с альтернативным ядром, и внезапно, проблема исчезает сама.

По классике - NOTABUG, штоп реопенинг!

Может и не запускает, но никакой неожиданной критической проблемы 32 потока на ядро не несут. Замедление работы? Разумеется, а как иначе? Плохо что повышенный nice нельзя выставлять от юзера, а вот мифические проблемы в ядре лично у меня не проявляются.

З.Ы. Пишу эту приписку под nice -n 20 stress -c 64. Полёт нормальный, фризы изредка и еле ощутимые, замедление незначительное.

Кстати, мне тут в голову одна мысль пришла: А как вообще планировщики должны работать на цпу с гиперпоточностью и не противоречит ли это идее smp? С другой стороны, i5-7500T без гиперпоточности, а вопросы к нему имеются.

В дебиане включено.

А если штатное ядро какого нибудь принципиально другого дистрибутива, да ещё версий на 10 вперёд или назад?

В девятке было выключено.

Не знаю, что там у тебя за идея и что чему противоречит, но работает нормально, попугаев бывает больше чем на венде и визуально всё летает, не как у ТС.

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

с 1024 тоже никакого эффекта

Так и не должно быть эффекта при vm.sched_autogroup_enabled=1. - Это дефолт на большинстве десктопов. В древних дебианах автогруппировки из коробки не было, и стол мог легко замерзать.

https://www.opennet.ru/opennews/art.shtml?num=29919

В состав ядра интегрирован патч с реализацией идеи автоматической группировки задач для повышения интерактивности на десктопе. Патч специальным образом разбивает выполняемые задачи на группы в привязке к идентификатору сессии, в дальнейшем планировщик задач оперирует данными группами как единым целым. Номер сессии изменяется при выполнении системной функции setsid(), которая, например, вызывается для каждого нового сеанса командной оболочки (тем не менее, при запуске десктоп приложений идентификатор сессии не меняется, т.е. если запустить в терминале «make -j 20», влияние на десктоп-приложения будет минимально

Ну и причём тут smt, если у тебя проц слабый и перегружается фоновой нагрузкой?

В состав ядра интегрирован патч с реализацией идеи автоматической группировки задач для повышения интерактивности на десктопе. Патч специальным образом разбивает выполняемые задачи на группы в привязке к идентификатору сессии, в дальнейшем планировщик задач оперирует данными группами как единым целым.

Это прекрасно, что пользователи получат некоторые бенефиты без возни с cgrulesengd и подобными решениями.
Но топик был как раз про то, что микролаги ничем не устраняются с ванильным планировщиком.
Процесс с одной cpu share успешно микрофризит процесс с 999.

P.S. С liquorix, к сожалению, пришлось вернуться на лагающий дефолт.
Там нет audit и ещё каких-то нужных мне вещей.

2.6.38

15.03.2011 12:53

Я за бан.

> В древних дебианах автогруппировки из коробки не было, и стол мог легко замерзать

Так вот почему у меня майн работает-работает, и раз в две минуты фризит на 0,2 секунды.

Как раз за одно ядро до этого избавились от Big Kernel Lock.

т.е. если запустить в терминале «make -j 20», влияние на десктоп-приложения будет минимально

В теории, на практике же кинцо не всегда нормально в этих условиях посмотреть можно. Например, с pipewire у меня с «-j8» на i7-2600 звук может иногда икать. Но вот замерзания курсора от нагрузки на cpu я еще не встречал.

В случае с -j8 проблема может быть в IO, а не в CPU.

stress -c 10000 у меня не вызывает прорблем. А вот с -j512 тормоза начинаются быстро.

Процессы компиляции читают и пишут на диск. Диск здесь узкое место, а не цп.

Процессы компиляции читают и пишут на диск. Диск здесь узкое место, а не цп.

У менч диск не узкое место (ssd, iowait - 0). Но вот странные проблемы из-за IO полностью исключать нельзя, они в линуксе на десктопе вылазят сколько я себя помню.

У меня слабый проц который НЕ перегружается фоновой нагрузкой. Потому что я знаю nice и cgrops, умею расставлять приоритеты и раскидывать задачи. 3-4 потока на ядро это не нагрузка.

С другой стороны у меня был интел атом 2 поколения, гиперпоточность там не отключалась и давала аж 5-7% производительности в компиляции и архивации. Зато просаживала фпс в любом шутере в 2 раза уже при 1,5 потока на ядро. Это неслабо чувствовалось уже в q3, а какой нибудь nexuiz просто терял всякий смысл если забыть прибить браузер с рекламным банером. Так вот, скорость потока была раза в 3 выше чем на RPi3, но на малине я легко смогу порубиться в q3 без просадки фпс под нагрузкой в 4 потока на ядро (15 потоков комплияции+q3), а более быстрый проц с гиперпоточностью просядет хоть убейся.

про шутер кстати напомнил, я читал на днях что вышла 1.3 версия assaultcube. завтра гляну

К счастью ассалт не меняется. Там нет смысла что либо менять.

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

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

Нет поддержки x86.

Пишешь нам из горящего арма? =D