История изменений
Исправление intelfx, (текущая версия) :
Температура одинаковая +/-
Потому что температура зависит в конечном счёте не от частоты, а от энергопотребления. А оно в обоих случаях практически одинаковое (смотри в последний столбец).
Вообще говоря, я думал, что в обоих случаях фактическая частота окажется одинаковой, а дело будет просто в том, что с acpi_cpufreq запрашиваемая ядром частота будет сильно отличаться от фактической, т. к. acpi_cpufreq — очень неточный механизм управления частотой. Как оказалось, нет, но происходящее всё равно объяснимо.
Кто виноват?
Драйвер и/или управляющий алгоритм (governor) cpufreq. Я так понимаю, у тебя там schedutil? Фишка в том, что при управлении через ACPI в зависимости от проца и прошивки доступна всего пара-тройка условных уровней частоты (ACPI P-states), и ядро при малой нагрузке скорее всего вынужденно выбирает один из наименьших (потому что иначе придётся выбрать наибольший, который уже в нелинейном участке). А при управлении процессором напрямую частоту можно задавать напрямую и ядро при возникновении любой нагрузки сразу выбирает условно-оптимальную (ну т. е. близкую к базовой), потому что race to idle и все дела.
У intel-овского драйвера (intel_pstate) алгоритмы более умные, там емнип есть несколько линейных и нелинейных участков, hardware feedback, bias-регистры и ещё куча всякой логики, в которой я не осилил разобраться, но schedutil тоже ничего.
Что делать? И надо ли вообще что-то делать?
Если нет проблем с энергопотреблением или чем-то ещё, ничего делать не надо.
Исправление intelfx, :
Температура одинаковая +/-
Потому что температура зависит в конечном счёте не от частоты, а от энергопотребления. А оно в обоих случаях практически одинаковое (смотри в последний столбец).
Вообще говоря, я думал, что в обоих случаях фактическая частота окажется одинаковой, а дело будет просто в том, что с acpi_cpufreq запрашиваемая ядром частота будет сильно отличаться от фактической, т. к. acpi_cpufreq — очень неточный механизм управления частотой. Как оказалось, нет, но происходящее всё равно объяснимо.
Кто виноват?
Драйвер и/или управляющий алгоритм (governor) cpufreq. Я так понимаю, у тебя там schedutil? Фишка в том, что при управлении через ACPI в зависимости от проца и прошивки доступна всего пара-тройка условных уровней частоты (ACPI P-states), и ядро при малой нагрузке скорее всего вынужденно выбирает один из наименьших (потому что иначе придётся выбрать наибольший, который уже в нелинейном участке). А при управлении процессором напрямую частоту можно задавать напрямую и ядро при возникновении любой нагрузки нагрузки сразу выбирает условно-оптимальную (ну т. е. близкую к базовой), потому что race to idle и все дела.
У intel-овского драйвера (intel_pstate) алгоритмы более умные, там емнип есть несколько линейных и нелинейных участков, hardware feedback, bias-регистры и ещё куча всякой логики, в которой я не осилил разобраться, но schedutil тоже ничего.
Что делать? И надо ли вообще что-то делать?
Если нет проблем с энергопотреблением или чем-то ещё, ничего делать не надо.
Исправление intelfx, :
Температура одинаковая +/-
Потому что температура зависит в конечном счёте не от частоты, а от энергопотребления. А оно в обоих случаях практически одинаковое (смотри в последний столбец).
Вообще говоря, я думал, что в обоих случаях фактическая частота окажется одинаковой, а дело будет просто в том, что с acpi_cpufreq запрашиваемая ядром частота будет сильно отличаться от фактической, т. к. acpi_cpufreq — очень неточный механизм управления частотой. Как оказалось, нет, но происходящее всё равно объяснимо.
Кто виноват?
Драйвер и/или управляющий алгоритм (governor) cpufreq. Я так понимаю, у тебя там schedutil? Фишка в том, что при управлении через ACPI в зависимости от проца и прошивки доступна всего пара-тройка условных уровней частоты (ACPI P-states), и ядро при малой нагрузке скорее всего вынужденно выбирает один из наименьших (потому что иначе придётся выбрать наибольший, который уже в нелинейном участке). А при управлении процессором напрямую частоту можно задавать напрямую и ядро при возникновении любой нагрузки нагрузки сразу выбирает условно-оптимальную (ну т. е. близкую к базовой), потому что race to idle и все дела.
У intel-овского драйвера (intel_pstate) алгоритмы более умные, там есть несколько линейных и нелинейных участков, hardware feedback, bias-регистры и ещё куча всякой логики, в которой я не осилил разобраться, но schedutil тоже ничего.
Что делать? И надо ли вообще что-то делать?
Если нет проблем с энергопотреблением или чем-то ещё, ничего делать не надо.
Исходная версия intelfx, :
Температура одинаковая +/-
Потому что температура зависит в конечном счёте не от частоты, а от энергопотребления. А оно в обоих случаях практически одинаковое (смотри в последний столбец).
Вообще говоря, я думал, что в обоих случаях фактическая частота окажется одинаковой, а дело будет просто в том, что с acpi_cpufreq запрашиваемая ядром частота будет сильно отличаться от фактической, т. к. acpi_cpufreq — очень неточный механизм управления частотой. Как оказалось, нет, но происходящее всё равно объяснимо.
Кто виноват?
Драйвер и/или управляющий алгоритм (governor) cpufreq. Я так понимаю, у тебя там schedutil? Фишка в том, что при управлении через ACPI в зависимости от проца и прошивки доступна всего пара-тройка условных уровней частоты (ACPI P-states), и ядро при малой нагрузке скорее всего вынужденно выбирает один из наименьших (потому что иначе придётся выбрать наибольший, который уже в нелинейном участке). А при управлении процессором напрямую частоту можно задавать напрямую и ядро при возникновении любой нагрузки нагрузки сразу выбирает условно-оптимальную (ну т. е. близкую к базовой, max linear performance), потому что race to idle и все дела.
У intel-овского драйвера (intel_pstate) алгоритмы более умные, там есть несколько линейных и нелинейных участков, hardware feedback, bias-регистры и ещё куча всякой логики, в которой я не осилил разобраться, но schedutil тоже ничего.
Что делать? И надо ли вообще что-то делать?
Если нет проблем с энергопотреблением или чем-то ещё, ничего делать не надо.