Как проверить поддержку big.little архитектуры в планировщике?

По моему выбор очень прост, особенно если ноутбук для работы. Для RHEL можно поставить новое ядро из ELRepo.

На выбор LTS https://elrepo.org/wiki/doku.php?id=kernel-lt

Или Mainline https://elrepo.org/wiki/doku.php?id=kernel-ml

Простите моё невежество, но big.LITTLE лет 10 уже. Интелу что-то особое надо? Если да, чем грозит отсутствие этой поддержки?

Простите моё невежество, но big.LITTLE лет 10 уже. Интелу что-то особое надо? Если да, чем грозит отсутствие этой поддержки?

Ну раз активно коммитят в ядро на эту тему, что-то точно надо. Я, кстати, совсем не уверен, что планировщик в андроиде (если речь о нём) тот же, что и в обычном линуксе.

К примеру у Intel есть фича под названием Thread Director. Процессор анализирует поток и в ядро передаёт какую-то информацию, которую ядро должно использовать для более грамотного планирования процессов. В винде эта штука поддерживается, в последних версиях линукса вроде тоже должна (но это не точно, почему-то в федоре я не нашёл ожидаемых пунктов в config, но может не разобрался).

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

А hyperthreading (SMT) на этих CPU выключить можно?

Можно скрафтить обёртку над cpuid+sched_setaffinity. Это правда не такой гибкий вариант, т.к. ядра жёстко связываются с потоком, в то время как существующие апи в оффтопиках это всего лишь хинт планировщику, а не жёсткий приказ

Можно. Более того по слухам следующее поколение у интела будет без HT в P ядрах

Вроде работает нормально с RHEL, судя по производительности запускает на нужных ядрах, оставлю как есть.

Но вот какие именно фичи они бэкпортируют - я не нашёл.

тынц

это плохой, ломучий совет

как вообще можно проверить работу планировщика наглядно

тынц

тынц

Capacity Aware Scheduling

Energy Aware Scheduling

Конечно лучше использовать чистый RHEL, но лучше RHEL с ELRepo чем Fedora.

Конечно лучше использовать чистый RHEL

Лучше и точка :)

Пока в голову приходит только

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

По-моему, в Линуксе до сих пор нет хорошей поддержки интеловоского big.LITTLE. Вот например, у меня i5-1340P и в нём 4 P ядер (с HT) и 8 E ядер (без HT). Запускаю я stress-ng -c 8. Что ожидается? Что все эти стресс потоки будут помещены на P ядра, а E ядра будут сачковать. А что в реальности? Где-то 3 E ядра загруженны на 100%, и остальное размазано по P ядрам.

Если же я явно запущу taskset --cpu-list 0-7 stress-ng -c 8, то все потоки будут как и ожидалось на P ядрах, а E ядра сачкуют.

Даже если запустить stress-ng -c 4, вроде 4 потока точно должны на P ядрах вместиться, то всё равно периодически они соскакивают на E ядра и обратно.

kernel 6.8.1.

Где-то 3 E ядра загруженны на 100%, и остальное размазано по P ядрам.

Подскажи, как это можно увидеть?

Чую какой-то подвох в твоём вопросике)

лет 10 уже

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

для игор отключают e-ядра но оставляют гипертред

Что ожидается?

исходя из чего ожидается?

По-моему, в Линуксе до сих пор нет хорошей поддержки интеловоского big.LITTLE. Вот например, у меня i5-1340P и в нём 4 P ядер (с HT) и 8 E ядер (без HT). Запускаю я stress-ng -c 8. Что ожидается? Что все эти стресс потоки будут помещены на P ядра, а E ядра будут сачковать. А что в реальности? Где-то 3 E ядра загруженны на 100%, и остальное размазано по P ядрам.

По идее приоритет P > E > P ht. Т.к. гиперпоток на быстром ядре гораздо медленней полноценного медленного ядра. Поэтому всё правильно делает.

вполне конкретные люди работают над этим, можете глянуть их патче-активность

https://lwn.net/Articles/909611/

тынц

Интересная информация в презенташке:

Pcore pull from Ecore, Ecore pull from HT, always

не знал это

неприличное видео 18+

В общем сидел на рхеле, но в конце концов тормоза достали. В идее что-то там запускается, мышка прям тормозить начинает. Двигаю курсор в верхний левый угол, чтобы окна скукожились, а они прям скачками скукоживаются, как будто у меня ноутбук 2000 года, а не 2024.

Конкретный юзкейс, воспроизводящий проблему - запустить openssl speed -multi +12 в трёх табах и после этого повзаимодействовать с системой. Это приводит к абсолютно очевидным тормозам. Предполагаю, что это сочетание того, что старый гном плохо использует GPU и того, что планировщик кидает процессы гнома на медленные ядра в такой ситуации.

Поставил федору 40, по субъективным ощущениям проблема ушла. Также тест, описанный выше, даёт совсем другой результат - несмотря на загрузку CPU отзывчивость DE остаётся идеальной, будто ничего и не запущено. Не уверен на 100%, что дело именно в планировщике, а не в более оптимальном коде гнома, конечно. Но по крайней мере курсор мышки не тормозит, блин, я такого уже 20 лет не видел.

А я уже писал про это всё. Что на такой архитектуре все программулины, которые под это не заточены - всегда будут работать с косяками. Потому что в ОС нет полной информации, для того, чтобы рулить всем этим хозяйством

Ну эвристика-то простая. Если процесс изредка просыпается - его сразу на быстрое, а кто на нём сидел - на медленное. Если процесс жрёт CPU без остановки, можно его вообще на быстрое не сажать. Это позволит редким задачам получать приоритет, а всякая компиляция пусть и будет на несколько десятков процентов дольше идти, да и пофиг. Самое главное это отзывчивость системы. Речь, конечно, про десктоп, понятно, что на сервере другие приоритеты, но там и процессоры такие не ставят.

А так - выбора просто нет, современные интелы только такие. Про AMD думал, но не решился. Может зря, не знаю. У меня АМД-фобия.

Если процесс жрёт CPU без остановки

Вот и коллизия. Жрать процесс без остановки может как какой-то демон, который в фоне сидит, так и процесс рендера. В этом и загвоздка планировщика, который стреляет то и дело мимо кассы и это можно пофиксить только прямым вмешательством в коде(программ, а не планировщика)

Это позволит редким задачам получать приоритет, а всякая компиляция пусть и будет на несколько десятков процентов дольше идти, да и пофиг

Ага, а те, кто рендерят - почему-то недовольны таким положением дел

Если бы этим можно было рулить вручную через систему приоритетов, то можно было бы Ananicy или подобным это всё тонко настраивать и оно было бы лучше, чем через планировщик

на несколько десятков процентов дольше идти

Ага, рендерится что-то час на Р ядрах. В фон свернул какой-то блендер и у тебя рендерится уже 2 часа :)

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

А так - выбора просто нет, современные интелы только такие. Про AMD думал, но не решился. Может зря, не знаю. У меня АМД-фобия.

А я решился. Хотя до этого всегда на интелах жил. Но такое я покупать для десктопа не буду

Ну при чём тут фон. Если более приоритетных задач нет - пускай рендерится на нормальных ядрах. А если я открыл браузер и тыкнул на ютуб, то эти несколько десятков миллисекунд CPU должны отобраться у рендера, пока ютубовский жаваскрипт отрабатывает. А потом вернётся.

Ну и вообще рендерить на ноутбуке с двумя нормальными ядрами это какой-то мазохизм.

Если более приоритетных задач нет - пускай рендерится на нормальных ядрах. А если я открыл браузер и тыкнул на ютуб, то эти несколько десятков миллисекунд CPU должны отобраться у рендера

Это всё красиво в теории, но видишь как оно работает на практике. Интел же вообще обещали аппаратно это сделать, но врали. И шедулером у них не получилось рулить так, чтобы всё, что не знало о такой архитектуре - работало. Но не просто работало, а было отзывчивей и быстрей

О чём речь? Из контейнеров я пользуюсь только докером, с которым проблем не ожидаю. Если про всякие флатпаки, я ими не пользуюсь. Да и вообще я, честно говоря, дистрибутивным софтом почти не пользуюсь, у меня 90% софта ставится либо из других репозиториев (хром, вскод), либо тупо вручную из архива в /opt (идея, ждк, нода, мавен и тд).

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

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

Федора ориентирована на контейнеры, а еще там ублюдский podman вместо нормального docker, который постоянно с какими-то багами

Если про всякие флатпаки

Ага, она по умолчанию из него VS Code ставит

Федора ориентирована на контейнеры

Хз, пока не сталкивался с этим.

а еще там ублюдский podman вместо нормального docker, который постоянно с какими-то багами

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

Ага, она по умолчанию из него VS Code ставит

Ну как я уже написал, я нужный мне софт из репозиториев дистрибутива не ставлю, если есть возможность ставить его от разработчика. У вскода есть свой репозиторий, из которого он ставится во вполне привычном виде. Есть исключения в виде мелких программ типа ripgrep, которые испортить пакетированием сложно. Но крупные пакеты вроде той же Java дистрибутивы зачем-то распиливают на кучу мелких, мутят какие-то там скрипты для переключения, в общем мне это всё категорически не нравится, поэтому я этим вообще не пользуюсь. Скачал tar.gz с adoptium, распаковал в /opt, раз в месяц проверил на наличие обновлений и всё.

Для меня федора это:

1. Привычный для меня инструментарий: нормальный systemd, dnf/yum. К примеру в дебиане, когда я последний раз смотрел, до сих пор были ошмётки init scripts, которые не пойми как взаимодействовали с systemd.

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

3. Достаточная популярность, чтобы рассчитывать на адекватное качество (то бишь на дистрибутиво-специфичные баги до меня кто-то наткнётся и их пофиксят).

4. Достаточно неплохие репозитории. К примеру в RHEL даже evtest не было, приходилось собирать из исходников.

5. Возможность offline обновления (сначала скачиваются пакеты, потом система перезагружается и в минимальном режиме устанавливает пакеты, потом перезагружается ещё раз). Это вообще считаю киллер-фичей, обожаю.

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

К федоре у меня есть мелкие претензии. К примеру инсталлятор в федоре вс какой-то странный, там даже от бтрфс нельзя отказаться, а он мне не нужен, я к ext4 привык. Но это я исправил просто установив систему с Everything iso. Или вот при установке 40 федоры я всегда настраиваю mirror, т.к. по дефолту федора мне подбирает нерабочие зеркала, вот в 40 нельзя настроить дополнительные mirrors, чтобы сразу установить обновления при установке, в итоге сначала ставится система, а потом при первой загрузке ещё надо ставить кучу обновлений. Ещё в федора-вс фаервол по дефолту можно сказать отключен, тоже странное решение. Но это всё ладно, работает как-то и слава богу.

Флатпаки и подобное я никогда не использовал. Пока получается обходиться без них. К тому времени, когда перестанет получаться - видимо разберусь в них досконально и начну пользоваться, вряд ли они настолько плохи, просто пока и без них нормально.

Дело не в планировщике и не в гноме. Это очень старая проблема с энергопотреблением iGPU и динамической тройной буфферизацией.

Если поставите platform profile «performance», то тромоза исчезнут. В mutter 46 проблему решили радикально, добавив тройную буфферизацию.

Интересно, спасибо, будем знать. Я предпочитаю ставить режим, который в гноме называется Power Saver (если я правильно понял, о чём речь), чтобы вентиляторы не жужжали даже под нагрузкой.

Основная моя претензия к федоре по сути это слишком большая скорость обновлений. Постоянно что-то там они обновляют, каждую неделю куча пакетов прилетает.

Не пробовал ограничиться только dnf update --security?

Хз, не уверен, что это хорошая идея, рано или поздно придётся же всё ставить.

который в гноме называется Power Saver (если я правильно понял, о чём речь)

Да,оно. Power management – дело тонкое, с ним постоянно бывает что-то не так. Это и Линукса касается, и Винды.

Вот, кстати, во вчерашнем 9.4 вот этот баг исправили: RHEL9 - is production ready? - готов к промышленной эксплуатации? (комментарий)

Раза в полтора время работы увеличилось. Сам igpu потребляет мало, но отсутствие dc6 на нем тянет за собой кучу всего остального.

во вчерашнем 9.4 вот этот баг исправили: RHEL9 - is production ready? - готов к промышленной эксплуатации? (комментарий)

поделитесь пжлст ссылкой на патч или что-то такое, спасибо

Они тупо бэкпортировали i915 из последней версии ядра. Так как это решило проблему, в баге, видимо, никто всерьез не разбирался.

В 9.3 было

# grep DC6 /sys/kernel/debug/dri/0/i915_dmc_info
DC5 -> DC6 count: 0

В 9.4 стало ок:

# grep DC6 /sys/kernel/debug/dri/0/i915_dmc_info
DC5 -> DC6 count: 73755

Что странно, с появлением гибридной графики юзерам дали конфигуратор, позволяющий задать профиль по умолчанию и конкретно вот для этого бинарника. Просто и максимально эффективно. А «пусть планировщик сам разберётся» - тут как со встречей динозавра на улице, 50/50, или угадает, или нет.

З.Ы. Собственно указание заглушить Р-ядра от батареи или загрузить их по полной на розетке должно быть оптимальным в 95% случаев, но имеет ли ядерный планировщик достаточный уровень функционала?

А производительность stress-ng -c 8 и taskset --cpu-list 0-7 stress-ng -c 8 как соотносятся? А то мало ли, вдруг оно и правда умное, упёрлось в теплоотвод и сделало лучше а не хуже...

Исходя из сравнения бенчей 14-ого поколения у меня закралось подозрение, что Р+хт оказываются не только быстрее, но ещё и энергоэффективнее.

Эффективность там по площади на кристалле, уже разжёвано десять раз. Амд уже выкатили аналог в виде zen4C.

запустить openssl speed -multi +12 в трёх табах и после этого повзаимодействовать с системой. Это приводит к абсолютно очевидным тормозам.

Тормоза не очевидны. Например на 4-х ядерном симетричном RPi4 с заниженными частотами. Пишу это сообщение прям под всеми 36-ю потоками нагрузки, даже без nice'а. На отзывчивости курсора вообще никак не сказывается, фризы во взаимодейстрии с элементами vivaldi всё таки появились.

Но дело в том, что на асиметричном интеле это реальный косяк планировщика, который и правда может быть усугубляется гномом, но косяк планировщика там точно есть. Кстати, у винды тоже был подобный косяк на 24-ядерных интелах, свежих на тот момент.

zen4C просто кеши режут и ещё хз как это скажется. Интелы уже доигрались до того, что амд с расширенным кешем их в играх нагнул, i7 быстрее и холоднее i9, а i3 в 4-х поточных нагрузках уступает i7 и i9 всего 10%, что длает старшие чипы бессмысленными.

Да, и похоже современному жирнокоду важен именно объём кеша а не частоты и продвинутость ядра. А тот код, которому не важен - он и паралелится легко, и на слабых ядрах хорошо живёт.