MuQSS

Кто в теме, рассказывайте, какие подводные джомолунгмы заготовлены на этот раз?

Предыдущий революционный улучшайзинг, который даже впихнули в ядро, был BFQ.
Потом внезапно оказалось что он не может в лимиты и все early adopters сейчас сидят в тредах об очередном userspace-oom.

Планировщик i/o для десктопа кладёт десктоп.

Мне нравится, что вы больны не мной, а головой.

ЕМНИП, для CFS недостаточно -j4. Ему подавай больше на 1 как минимум. А вообще, конечно, kbuild тоже больной.

Насчёт большого LA, поиграйся с nohz.

ЕМНИП, для CFS недостаточно -j4. Ему подавай больше на 1 как минимум

Настройки одинаковые что с патчем, что без него. Конечно, компиляю в несколько потоков.

Вопрос именно к CFS: можно ли его настроить на более активную загрузку ядер?

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

для CFS недостаточно -j4

Увеличивал количество потоков компиляции – результат не изменился. Всё также ядра работают в полсилы.

У тебя powersave, может?

Имеется 4-ядерный проц.

Может 2-ядерный с 4 потоками? И возможно всякие защиты от мельдония, спектра и что там еще на позволяют загрузит все потоки.

У тебя powersave

Нет, ondemand.

Может 2-ядерный с 4 потоками?

Нет, гипертрединга нет. Проц N3540.

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

Так с патчем MuQSS с теми же самыми настройками ядро нагружается по полной, почему тогда с CFS совсем другая история?

Пробую собирать с nohz_full и разными CPU sheduler runqueue sharing. Пока только тормоза вместо скорости получаются.

ondemand

А что с performance?

performance не интересует, потому что комп работает от батарейки.

Ядро с патчем muqss и параметрами nohz_full=1-3 rcu_nocbs=1-3 через несколько минут работы впадает в ступор (невосстанавливаемый фриз).

performance не интересует

А меня интересует. Для сравнения. А потом пользуй, что хочешь.

Скомпилял с performance, выставил в tlp – результат не изменился. Менял CONFIG_SCHED_AUTOGROUP – тоже без разницы. Загружаться на 400% CFS не хочет :(

N3540

Baytrail atom. Извращенец. Он под ванильным ядром только в последних патчах 5.3 начал более менее работать, а лучше перейди на 5.4. Он не работатет, а ты его хочешь работой загрузить.

ты че компилирование в один поток, разбивал на 4 ядра через планировщик? чето не представляю как это работает

выше сказали уже, почему просто не -j4

Тут не в этом дело, а в том, как планировщик щелкает между потоками, что само по себе ресурсоёмко. Этот щелкает меньше.

cgroups не поддерживает, в deadline не умеет

Так с патчем MuQSS с теми же самыми настройками ядро нагружается

попробуй ядро какогото дистра дефолтного(убунту или тчо еще), может у тебя гдето в другом месте ошибка в сборке… сколько сижу на дефолтном планировщике никогда компиляция не тормозила

лучше перейди на 5.4

Так и есть, у меня 5.4.

cgroups не поддерживает, в deadline не умеет

MuQSS без cgroups? Ну его на фиг – чем тогда процессы и использование памяти ограничивать? CFS наше всё.

попробуй ядро какогото дистра дефолтного

Я сравнивал работу дефолтного арчевского и со своим конфигом. На дефолте такая же недогрузка.

ты че компилирование в один поток, разбивал на 4 ядра через планировщик?

Нет, компилирую обычно с -j8.

Офигительные истории. Отруби энергосбережение, например.

Проблема появилась в последних версиях ядра. На четвёрке такого не было, а ниже 5.3 опускаться N3540 не хорошо, потому что в этой версии исправили косяки со фризами, бывшие в 4-й ветке.

Багзилла ядра по другому адресу находится.

N3540 Так и есть, у меня 5.4.

Тебе принципиально этот атом нужен? Помню был баг, вроде этот https://bugzilla.kernel.org/show_bug.cgi?id=109051 . Говорят, только в 5.4 его исправили. Некоторые пишут, что у них до сих пор рандомно виснет без этого параметра. А с этим параметром, считай что проц не ипользует энергосбережение, которое ты хочешь.

Мне кажется, ты выбрал не тот процессор, тем более для экспериментов с планировщиком.

Baytrail atom. Извращенец.

Пф. Из мобильных средней цены рядом с N3540 не лежал ни один другой проц интела и амд: TDP 7,5 Вт, gpu 896 MHz. Я с ним кайфую + абсолютно тихий, ибо нет вентилятора.

Некоторые пишут, что у них до сих пор рандомно виснет без этого параметра.

Нет, начиная с 5.3 исправили. В простое 2,75 Вт. кушает. С энергосбережением всё норм.

Багзилла ядра по другому адресу находится.

Я отчёты на багзиллу отправлял. Проблему исправили. В этой теме речь о планировщике.

Отруби энергосбережение, например.

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

Пф. Из мобильных средней цены рядом с N3540 не лежал ни один другой проц …

Может потому он дешевый, что глючный?

Пф. Из мобильных средней цены рядом с N3540 не лежал ни один другой проц …

Может потому он дешевый, что глючный?

Отруби энергосбережение, например.

Какой в этом смысл?

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

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

Проблема точно не в проце, потому что с MuQSS загружается на 400%. Но с MuQSS другая проблема: ядро быстро съедает батарейку даже в простое.

Проблема точно не в проце, потому что с MuQSS загружается на 400%.

MuQSS может тупо заспамить проц прерываниями (например), что проц просто не переходит в режим энергосбережения, из-за чего не проявляется баг.

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

Не компиляй тогда на нём, лол. Можно отключить на время а потом включить обратно.

Нет, компилирую обычно с -j8.

ну это реально похоже на проблему с энергосбережением(может в ядре чтото криво)

процессор же по дефолту без нагрузки крутит около 1ггц, и под нагрузкой разгоняется до полной, похоже что у тебя просто както криво разгоняется или медленно…

у меня никакой недогрузки нет, на дефолтных ярах на разных процессорах

Проблема точно не в проце, потому что с MuQSS загружается на 400%. Но с MuQSS другая проблема: ядро быстро съедает батарейку даже в простое.

ну вот… MuQSS крутит ядро на 100% постоянно просто, может так

но мне не нравится, что в простое у него Load average 0.80 это скорее всего баг с фейковой нагрузкой, так что можешь забить на это

но мне не нравится, что в простое у него Load average 0.80

это скорее всего баг с фейковой нагрузкой, так что можешь забить на это

*быстрофикс

бтв можешь это попробывать

на райзенах есть траблы

http://cchalpha.blogspot.com

чем не устраивает mq-deadline?

Техновыходные

Снова привет.

На выходных нашлось время прочитать кучу документации и статей + потестить разные настройки ядра. Все варианты проверял одним единственным тестом – замерял время сборки ядра. Выводы:

• nohz_full – зло! Вешая все таймеры на первое ядро параметром nohz_full=1-3 «освободившиеся» ядра заваливаются прерываниями типа «Rescheduling». В связи с этим остальные ядра в более глубокие С-состояния чаще не входят, энергопрофита нет. tickless idle – наше всё!
• Вешая все прерывания драйверов и подсистему RCU на первое ядро параметрами rcu_nocbs=1-3 rcu_nocb_poll irqaffinity=0, профита в производительности остальных ядер не наблюдается. В простое с такой настройкой процессор ест больше.
• performance – самый экономичный governor! Для ядра самое энергоэкономичное поведение – быстро выполнить задачи и скорее заснуть. В этом смысле нет профита, когда одно ядро работает на полную, а остальные спят. Нет профита и от powersave, потому что ядро на низких частотах дольше находится в пробуждённом состоянии (+ 0.3 Вт⋅ч в простое при сравнении с performance!). Несколько раз тестировал: больше никаких ondemand-ов и powersave-ов.
• CFS by design может хорошо нагружать процессор только с большим количеством задач, потому что между всеми задачами типа SCHED_OTHER делит процессорное время поровну. В моём случае загрузки 350%+ удаётся достичь с -j16+, т. е. минимум по 4 задачи на одно ядро.
• Можно загрузить проц ещё больше, запуская задачи rt-планировщиком. Для компиляния, т. е. большого кол-ва маленьких задач, лучше всего подходит SCHED_FIFO. Профит достигается за счёт того, что ядро не тратит ресурсы на смену контекста при переключении задач до тех пор, пока текущая не будет выполнена. Это прекрасно, но есть один минус – запуская сборку такой командой:

time sudo chrt -f 1 runuser -u $(whoami) -- makepkg

компьютером пользоваться невозможно из-за 95%-ой монополии ядра rt-процессами. Для решения этой делемы сборку выполняю как обычно:

time makepkg

а параллельно запускаю скрипт такого содержания:

#!/bin/bash
echo "gcc-rt-scheduler is running"

# во избежание блокировки скрипта rt-процессами
taskset -p 1 $$ &>/dev/null

while true
    do ps --no-headers -L -C "cc1" -o lwp,cpuid \
        | awk '$2 != 0 {print $1}' \
        | while read -r pid
            do chrt -f -p 1 ${pid} 2>/dev/null
          done
    sleep 1
done

У него смысл такой: раз в секунду сс1 просессы, находящиеся на исполнении на всех ядрах, кроме 0-го, передаются rt-планировщику SCHED_FIFO. В этом случае 1-3 ядра по факту становятся RT, но компиляция также продолжается и на 0-м ядре под руководством планировщика SCHED_OTHER. Система не блокируется и компьютером можно пользоваться для лёгких задач. Профит производительности составляет минус одна минута из 28-ми. Оно того стоит?

• Кроме этого потестил другие опции. Например, отключение «SLUB per cpu partial cache» увеличивает время сборки на 2 минуты. CONFIG_PREEMPT в сочетании с CONFIG_HZ_100 немного сократил время сборки. «На глаз» компьютер меннее отзывчивым не стал, а экономия 30 секунд из получаса радует. В этом случае планировщик реже тратит ресурсы на смену контекста. 100x4 прерываний в секунду – более чем достаточно для десктопа.
• Наиболее энергоэкономичное состояние достигается равномерным распределением прерываний по всем ядрам. У меня это работает из коробки. Кто испытывает проблемы со сваливанием всех hardirq на 0-е ядро может использовать irqbalance.
• Применяя jemalloc, время сборки увеличивается на 1 минуту. Победа этого аллокатора в разных бенчмарках разбивается об реальную задачу.

«Ревизия ядра» оказалась полезной. Заодно подтянул энергосбережение i915, отремонтировал тачпад.
Всем исследователям настроек ядра желаю успехов!

Не знаю над чем ты извращаешься. Достал ноут с n3530. Никаких проблем с многозадачностью, на ванильном ядре (5.4) ванильное ядро компилируется на всех 4 процессорных ядрах. Правда без intel_idle.max_cstate=1 также спонтанно зависает, но вроде чуть реже.

CONFIG_HZ_100

Во-во, давно так ставлю. А в школогайдах вечно советовали 1000.

У меня больше никаких зависаний нет, ядра в С7 находятся сколько угодно долго. Там трабла была с С6: сейчас пофиксили тем, что проц это состояние пропускает – сразу идёт в С7 и всё норм.

Там трабла была с С6: сейчас пофиксили тем, что проц это состояние пропускает – сразу идёт в С7 и всё норм.

Мы живем в разных мирах. Ты либо сказозный п…дабол, либо головой поехал.

У меня на ноуте ванильное ядро 5.4. Powertop говорит, что 99% времени проц находится в «С6 (сс6)» (из их частично в c6s, c6n, но в основном с7). Ничего не пропускает.

Патч с багтрекера для пропуска этих c6s, c6n не работает. Да, чуть помогает. Да, реже зависает. Но все равно зависает, может на первой же минуте зависнуть, может неделю прорабтать и зависнуть.

А в ванильном ядре поправили логику работы с этими состояниями, но так и недоправили. В общем, все равно виснет. Реже, но виснет.

Или это баг самого проца, тк помню, что на win8.1 так же зависал.

Мы живем в разных мирах. Ты либо сказозный п…дабол, либо головой поехал.

Довольно оригинальный способ подключиться к дискуссии – через оскорбления. Людей с грязными ртами как ты становится всё меньше, они вымирают, и это в целом – положительное явление.

Смотри, n3540 – продукт семейства процессоров Bay Trail. Его C-состояния управляются драйвером intel_idle. Можно взглянуть на текст драйвера (drivers/idle/intel_idle.c) в ванильном ядре 5.4 и увидеть, что при определении семейства Bay Trail драйвер выставляет специальный флаг .byt_auto_demotion_disable_flag,

   996 static const struct idle_cpu idle_cpu_byt = {
   997     .state_table = byt_cstates,
   998     .disable_promotion_to_c1e = true,
   999     .byt_auto_demotion_disable_flag = true,
  1000 };

который не даёт процессору без особых на то инструкций находиться в C6 состояниях:

  1376     if (icpu->byt_auto_demotion_disable_flag) {
  1377         wrmsrl(MSR_CC6_DEMOTION_POLICY_CONFIG, 0);
  1378         wrmsrl(MSR_MC6_DEMOTION_POLICY_CONFIG, 0);
  1379     }

По поводу винды ничего сказать не могу – у меня её нет.

Вот ещё по сути вопроса: какое-то время назад я заморочился и исправил ошибки в DSDT таблице биоса, собрал интеловским компилятором. Ядро собираю всегда со свой DSDT таблицей. Я до сих пор не знаю, связано ли улучшение ситуации с этим либо с переходом на ядро 5.3 – это два события несколько месячной давности. Но вот как год у меня не случилось ни единого зависания.

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

На проц наезжать не нужно – он офигенски производительный для своего класса. При этом абсолютно бесшумный (без куллера).

Желаю тебе удачи справиться со фризами.

jemalloc

tcmalloc или свежий mimalloc не пробовал?

По поводу Powertop. Во-первых, есть основания сомневаться в точности его показаний. Например, из того же drivers/idle/intel_idle.c видим разрешённые для Bay Trail состояния:

   197 static struct cpuidle_state byt_cstates[] = {
   198     {
   199         .name = "C1",
   200         .desc = "MWAIT 0x00",
   201         .flags = MWAIT2flg(0x00),
   202         .exit_latency = 1,
   203         .target_residency = 1,
   204         .enter = &intel_idle,
   205         .enter_s2idle = intel_idle_s2idle, },
   206     {
   207         .name = "C6N",
   208         .desc = "MWAIT 0x58",
   209         .flags = MWAIT2flg(0x58) | CPUIDLE_FLAG_TLB_FLUSHED,
   210         .exit_latency = 300,
   211         .target_residency = 275,
   212         .enter = &intel_idle,
   213         .enter_s2idle = intel_idle_s2idle, },
   214     {
   215         .name = "C6S",
   216         .desc = "MWAIT 0x52",
   217         .flags = MWAIT2flg(0x52) | CPUIDLE_FLAG_TLB_FLUSHED,
   218         .exit_latency = 500,
   219         .target_residency = 560,
   220         .enter = &intel_idle,
   221         .enter_s2idle = intel_idle_s2idle, },
   222     {
   223         .name = "C7",
   224         .desc = "MWAIT 0x60",
   225         .flags = MWAIT2flg(0x60) | CPUIDLE_FLAG_TLB_FLUSHED,
   226         .exit_latency = 1200,
   227         .target_residency = 4000,
   228         .enter = &intel_idle,
   229         .enter_s2idle = intel_idle_s2idle, },
   230     {
   231         .name = "C7S",
   232         .desc = "MWAIT 0x64",
   233         .flags = MWAIT2flg(0x64) | CPUIDLE_FLAG_TLB_FLUSHED,
   234         .exit_latency = 10000,
   235         .target_residency = 20000,
   236         .enter = &intel_idle,
   237         .enter_s2idle = intel_idle_s2idle, },
   238     {
   239         .enter = NULL }
   240 };

Запускаем Powertop:

|            CPU(OS) 0
| C0 active   2,4%
| POLL        0,0%    0,1 ms
| C1          0,1%    0,1 ms
|
| C6S         1,2%    1,0 ms
| C6N         0,7%    0,7 ms
| C7         28,2%   12,4 ms

Ок, по тегам информация сходится, но в каком состоянии процессор находился ~70% остального времени? Это раз. В колонке Pkg(HW) он показывает:

C2 (pc2)    0,0%
C3 (pc3)    0,0%
C6 (pc6)    0,0%

Ни в С3, ни в С3, ни в С6 состояния процессор не входит. Верю.

Узнай на какое состояние указывает Powertop под тегом C6 (cc6), и тогда возвращайся.