LINUX.ORG.RU

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

 


0

4

У меня ноутбук с 1355U. На нём 2 быстрых ядра и 8 медленных.

Насколько я нагуглил, поддержка Alder Lake (первая архитектура с разными ядрами) появилась в ядре 5.13. Но с тех пор в разных патчах её дорабатывали.

В первую очередь меня беспокоит именно поддержка со стороны планировщика. Чтобы он понимал (честно говоря даже не представляю, как), какие процессы надо на быстрые ядра распределять, а какие - на медленные. Полагаю, что это очень сильно будет влиять на опыт использования компьютера.

Я сейчас выбираю между RHEL и Fedora. В Fedora ядро достаточно новое и лучше уже не будет, это понятно. Но она мне не очень нравится по некоторым другим причинам (слишком быстро обновляется, слишком современный софт). RHEL меня устраивает всем, кроме именно этого нюанса.

Мой ноутбук вроде сертифицирован для RHEL, но это ведь значит лишь то, что там всё как-то работает. В последнем RHEL ядро 5.14, но понятно, что эта цифра сама по себе ни о чём не говорит, т.к. они бэкпортируют некоторые фичи из новых версий. Но вот какие именно фичи они бэкпортируют - я не нашёл.

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

Пока в голову приходит только несколько раз позапускать какой-то тест, грузящий CPU, вроде openssl speed. И убедиться, что пока их запущено не более двух штук, то они выдают максимально возможную скорость (т.е. пока доступны быстрые ядра, планировщик не будет использовать медленные).

Вообще в макоси в API есть возможность указать, что поток должен работать на медленном ядре. И нормально написанные приложения этой возможностью пользуются. Поэтому там с какой-то точки зрения работа планировщика даже проще. В Linux, я так понимаю, ничего подобного нет и для планировщика все потоки изначально равны и только по каким-то эвристикам он может понять, какие из них важней для пользователя?

★★★★

Ответ на: комментарий от vbr

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

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

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

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

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

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

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

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

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

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

Они тупо бэкпортировали 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
i586 ★★★★★
()