Как настроить Linux для полного AMD поддержка управления питанием APU: Турбо Ядро, Cool'n'Quiet, Динамическое Управление питанием?

Ваш сценарий жемчуга в середине, вероятно, страдает от буферизации. Попробуйте команды без | /home/Beer/./addtimestamp.pl. Если это разрешает, что проблема пытается добавить:

$| = 1;

к сценарию жемчуга.

11
09.11.2015, 15:50
1 ответ

[Edit: Заключительные мысли относительно выбора процессора]

  • AMD против AMD:
    • Ричленд здесь работает лучше, чем Тринити.
    • Kaveri не может конкурировать с рассеиваемой мощностью в холостом режиме Richland (по крайней мере, на данный момент).
    • Графический процессор A10-6700 может быть переоценен, но, к сожалению, он не будет использоваться много раз. Некоторые алгоритмы могут использовать его вычислительную мощность. Однако не знаю, как это повлияет на энергопотребление процессора.
    • Я подозреваю, что A10-6790K - это тот же процессор, что и A10-6700, только с другим набором параметров для ускорения Turbo Core. Если это правда, A10-6790K сможет дольше разгоняться и / или обеспечивать более высокие частоты в долгосрочной перспективе из-за более высокого TDP. Но для этого вам понадобится другой вентилятор процессора (подумайте о пространстве и температуре / сроке службы).
  • AMD A10-6700 против Intel Core i3-3220:
    • У A10-6700 намного больше мощности графического процессора, которая здесь не используется.
    • i3-3220 имеет меньшее рассеивание мощности в режиме ожидания.
    • Хотя в типичных тестах i3-3220 быстрее выполняет вычисления, я не вижу, как его два ядра с гиперпоточностью смогут обрабатывать параллельные запросы (скажем, к базе данных с веб-интерфейсами) так же быстро, как четыре полнофункциональных ядра. (по крайней мере, если предположить серьезное кеширование). Но серьезных тестов не нашел - только некоторые указания.

[Изменить: параметр bapm бесплатного драйвера Radeon установлен по умолчанию для систем Kaveri, Kabini и настольных систем Trinity, Richland начиная с Linux 3.16]

См. [pull] radeon drm-fixes-3.16 .

Однако, что касается Debian на базе 3.16, значения по умолчанию (пока?) Не работают, в то время как параметр загрузки работает. См. Как настроить систему Debian (фокус на 2D или консоль / сервер) с APU AMD Turbo Core для максимальной энергоэффективности и вычислительной эффективности?

[Изменить: бесплатный драйвер Radeon скоро будет иметь параметр bapm ]

Поскольку нижняя строка ниже - это использовать исправленную версию бесплатного radeon с вашим APU для поддержки Turbo Core и получения от него максимальной отдачи (кроме трехмерной графики), если вы можете (включение bapm может привести к нестабильности в некоторых конфигурациях), это отличная новость, что в будущих версиях radeon будет параметр для включения bapm .

[Исходное сообщение следует]

AMD A10-6700 (Richland) APU Experience

Выбор процессора

Моим первым компьютером был 486DX2-66, собранный из десятков 3,5-дюймовых гибких дисков, содержащих Slackware Таким образом, многое изменилось, и многие отрасли в настоящее время, похоже, находятся в стадии, когда они все еще увеличивают количество вариантов продукта.

Это обстоятельство и некоторые неудачные решения AMD в недавнем прошлом не упростил мне выбор платформы для мини-сервера. Но в конце концов я решил, что A10-6700 будет хорошим выбором:

  • Несколько обзоров показали, что (все еще широко недоступный) Kaveri будет потребляют больше энергии в режиме ожидания, чем Richland или Trinity
  • . Преимущество Richland A10-6700 над Trinity A10-5700 кажется значительным: более низкая минимальная и более высокая максимальная частота, более мелкозернистый Turbo Core (учитывая также температура - большое преимущество, когда графический процессор простаивает)
  • Графический процессор A 10-6700 считается переоцененным (маркетинговое название), а цены на APU кажутся справедливыми

Другие компоненты и настройка

Несмотря на бесчисленное количество процессоров на выбор, плат Mini-ITX не так много. ASRock FM2A78M-ITX + оказался разумным выбором. Тест проводился с прошивкой V1.30 (на момент написания этой статьи обновлений не было).

Должно потребляться только 80% номинальной мощности источника питания. С другой стороны, многие не могут эффективно работать при нагрузке ниже 50%. Очень сложно найти энергоэффективный источник питания для системы с расчетным диапазоном рассеиваемой мощности от 35 Вт до 120 Вт. Я провел эти тесты с Seasonic G360 80+ Gold, потому что он превосходит большинство конкурентов по эффективности при низких нагрузках.

Два 8 ГБ ОЗУ DDR3-1866 (сконфигурированные как таковые - что действительно имеет значение по сравнению с 1333), один SSD-накопитель и вентилятор ЦП с регулируемым качеством ШИМ также были частью тестовой установки.

Измерения проводились с использованием AVM Fritz! DECT 200, который, как сообщается, выполняет точные измерения. Тем не менее, правдоподобие было подтверждено с использованием более старого безымянного устройства. Несоответствий выявить не удалось. Измеренная рассеиваемая мощность системы будет включать снижение эффективности источника питания при более низких нагрузках.

Экран [W] QHD был подключен через HDMI.

Исходная общая память для графического процессора была установлена ​​на 32 МБ в UEFI BIOS. Кроме того, встроенный графический процессор был выбран в качестве основного и был включен IOMMU.

Ни X, ни другая графическая система не была установлена ​​или настроена. Вывод видео был ограничен консольным режимом.

Основы

Есть несколько вещей, которые нужно знать.

  • В то время как решение о Cool'n'Quiet принимается программным обеспечением вне процессоров, Turbo Core - это решение, принимаемое автономно дополнительным микроконтроллером на APU (или CPU).
  • Многие инструменты, а также места / proc и / sys не сообщают об активности Turbo Core. cpufreq-aperf , cpupower frequency-info и cpupower monitor работают, но только после modprobe msr .

Группа тестов 1: Linux + radeon

Я начал со свежего Arch Linux (установщик 2014.08.01, ядро ​​3.15.7). Ключевым фактором здесь является наличие acpi_cpufreq (масштабирование процессора ядра) и radeon (драйвер графического процессора ядра), а также простой способ обновления radeon .

Тестовый пример 1.1: BIOS TC включен - CnQ on / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting............................ Enabled
UEFI BIOS Cool'n'Quiet Setting.......................... Enabled
/sys/devices/system/cpu/cpufreq/boost................... 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand 
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800
Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700
Observed "cpupower monitor" Freq range... 1800 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load           | Core Freqs
---------------+-----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Тестовый пример 1.2: BIOS TC включен - CnQ on / Linux Performance - Boost

UEFI BIOS Turbo Core Setting............................ Enabled
UEFI BIOS Cool'n'Quiet Setting.......................... Enabled
/sys/devices/system/cpu/cpufreq/boost................... 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... performance 
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800
Observed "/proc/cpuinfo" cpu MHz range... 3700
Observed "cpupower monitor" Freq range... 2000 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load           | Core Freqs
---------------+-----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Обзор группы 1 тестов

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


Группа тестовых примеров 2: Linux + radeon с исправлением bapm

Чтобы включить bapm , я начал со свежего Arch Linux (установщик 2014.08.01, ядро ​​3.15.7), получил пакет core linux через ABS (3.15.8), отредактировал PKGBUILD , чтобы использовать pkgbase = linux-tc , вытащил исходники с помощью makepkg --nobuild , изменил pi-> enable_bapm = true; в trinity_dpm_init () в src / linux-3.15 / drivers /gpu/drm/radeon/trinity_dpm.c и скомпилировал его с помощью makepkg --noextract . Затем я установил его ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xz и pacman -U linux-tc-3.15.8-1 -x86_64.pkg.tar.xz ) и обновленный GRUB ( grub-mkconfig -o /boot/grub/grub.cfg но, конечно, YMMV).

В результате мне было предложено загрузить linux или linux-tc , и следующие тесты относятся к последнему.

Тестовый пример 2.1: BIOS TC включен - CnQ on / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting............................ Enabled
UEFI BIOS Cool'n'Quiet Setting.......................... Enabled
/sys/devices/system/cpu/cpufreq/boost................... 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand 
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800
Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700
Observed "cpupower monitor" Freq range... 1800 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load           | Core Freqs
---------------+-----------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 4100
stress --cpu 3 | 3 x 4100 .. 3900
stress --cpu 4 | 4 x 4000 .. 3800

Тестовый пример 2.2: BIOS TC включен - CnQ включен / Linux Performance - Boost

UEFI BIOS Turbo Core Setting............................ Enabled
UEFI BIOS Cool'n'Quiet Setting.......................... Enabled
/sys/devices/system/cpu/cpufreq/boost................... 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... performace
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800
Observed "/proc/cpuinfo" cpu MHz range... 3700
Observed "cpupower monitor" Freq range... 2000 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load           | Core Freqs
---------------+-----------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 4100
stress --cpu 3 | 3 x 4100 .. 3900
stress --cpu 4 | 4 x 4000 .. 3800

Тестовый пример 2.3: BIOS TC включен - CnQ включен / Linux OnDemand - без ускорения

UEFI BIOS Turbo Core Setting............................ Enabled
UEFI BIOS Cool'n'Quiet Setting.......................... Enabled
/sys/devices/system/cpu/cpufreq/boost................... 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800
Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700
Observed "cpupower monitor" Freq range... 1800 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... power level 1
Load           | Core Freqs
---------------+-----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Тестовый пример 2.4: BIOS TC включен - CnQ включен / Производительность Linux - Нет Boost

UEFI BIOS Turbo Core Setting............................ Enabled
UEFI BIOS Cool'n'Quiet Setting.......................... Enabled
/sys/devices/system/cpu/cpufreq/boost................... 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... performace
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800
Observed "/proc/cpuinfo" cpu MHz range... 3700
Observed "cpupower monitor" Freq range... 2000 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... power level 1
Load           | Core Freqs
---------------+-----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Тестовый пример 2.5: BIOS TC выключен - CnQ включен / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting............................ Disabled
UEFI BIOS Cool'n'Quiet Setting.......................... Enabled
/sys/devices/system/cpu/cpufreq/boost................... 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand 
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800
Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700
Observed "cpupower monitor" Freq range... 1800 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... power level 0

Другими словами, если Turbo Core отключен в BIOS, пропатченный radeon не включит его.

Тестовый пример 2.6: BIOS TC включен - CnQ выключен / Linux нет.

UEFI BIOS Turbo Core Setting............................ Enabled
UEFI BIOS Cool'n'Quiet Setting.......................... Disabled
/sys/devices/system/cpu/cpufreq/boost................... n/a
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... n/a
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800
Observed "/proc/cpuinfo" cpu MHz range... 3700
Observed "cpupower monitor" Freq range... 2000 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... power level 0
Load           | Core Freqs
---------------+-----------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4100 .. 4000
stress --cpu 3 | 3 x 4000 .. 3800
stress --cpu 4 | 4 x 3900 .. 3700

При отключенном Cool'n'Qiet ядро ​​Linux не предлагает никакого выбора регулятора и (ошибочно) предполагает, что ядра работают с фиксированным частота. Интересно, что результирующие частоты Turbo Core являются худшими из всех протестированных комбинаций в группе тестовых примеров 2.

Обзор группы тестовых примеров 2

Turbo Core работает с исправленным драйвером radeon . Никаких нестабильностей (которые являются причиной отключения там bapm aka Turbo Core) до сих пор не наблюдалось.


Группа тестов 3: Linux + fglrx (Catalyst)

Я начал с новой установки Ubuntu (14.04 Server, ядро ​​3.13), которую я считаю сопоставимой с Arch Linux (установщик 2014.08.01, ядро ​​3.15. 7) из-за наличия acpi_cpufreq (масштабирование процессора ядра) и radeon (драйвер графического процессора ядра). Причина перехода на Ubuntu - простая установка fglrx . Я проверил энергопотребление и поведение на новой установке, использующей radeon .

Я установил fglrx из командной строки ( sudo apt-get install linux-headers-generic , sudo apt-get install fglrx ) и перезагрузил система. Переход с radeon на fglrx сразу очевиден как в отношении внешнего вида консоли ( fglrx : 128 x 48, radeon : намного выше), так и Потребляемая мощность в режиме ожидания ( fglrx : 40 Вт, radeon : 30 Вт). Но Turbo Core работает сразу.

Тестовый пример 3.1: BIOS TC включен - CnQ включен / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting............................ Enabled
UEFI BIOS Cool'n'Quiet Setting.......................... Enabled
/sys/devices/system/cpu/cpufreq/boost................... 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... ondemand 
"cpupower frequency-info" Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800
Observed "/proc/cpuinfo" cpu MHz range... 1800 - 3700
Observed "cpupower monitor" Freq range... 1800 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... n/a
Load           | Core Freqs
---------------+----------------------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 3900 (core chg)
stress --cpu 3 | 3 x 4100 .. 3700
stress --cpu 4 | 4 x 4000 .. 3600

Поведение fglrx определенно интересно. Когда вызывалось «stress --cpu 2» для любого из тестовых случаев в любой группе тестовых примеров, два загруженных ядра всегда располагались на отдельных модулях. Но с fglrx произошло внезапное перераспределение, так что использовался единственный модуль (что значительно экономит энергию, см. Ниже). Через некоторое время загруженное ядро ​​переместилось обратно в другой модуль. Этого не было у radeon . Может быть, fglrx манипулирует сродством ядра процессов?

Сводка группы тестовых примеров 3

Преимущество fglrx заключается в том, что он сразу включает Turbo Core, без необходимости исправлять его.

Поскольку fglrx тратит от 10 до 12 Вт для графического процессора в нашем сценарии на чипе с TDP 65 Вт, общие результаты относительно доступных частот ядра не впечатляют. Поэтому дальнейшие испытания не проводились.

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


Сводка энергопотребления

Некоторые дельта-значения в следующей таблице немного ухудшаются при повышении температуры; можно сказать, вентилятор с ШИМ-управлением и чип играют здесь роль.

System @State / ->Transition Delta | System Power Dissipation
-------------------------------------+-------------------------
  @BIOS                            |  @ 95 .. 86W
  @Bootloader                      |  @108 .. 89W
  @Ubuntu Installer Idle           |  @ 40W
  @Linux radeon Idle ondemand      |  @ 30W
  @Linux radeon Idle performance   |  @ 30W
  @Linux fglrx Idle ondemand       |  @ 40W
  1 Module 1800 -> 3700            |  + 13W
  1 Module 1800 -> 4300            |  + 25W
  1 Core 1800 -> 3700              |  +  5W
  1 Core 1800 -> 4300              |  + 10W
  "radeon" Video Out -> Disable    |  -  2W
  'fglrx" Video Out -> Darken      |  +- 0W
  @Linux radeon Maximum            |  @103 .. 89W
  @Linux fglrx Maximum             |  @105 .. 92W
  • Похоже, что Turbo Core (по крайней мере, с APU Richland) больше, чем ожидалось: нет заметной разницы в рассеивании мощности, когда установлен регулятор масштабирования ondemand, по сравнению с регулятором производительности. место. Althouth / proc / cpuinfo всегда будет сообщать 37000 МГц под регулятором производительности, cpupower monitor покажет, что ядра действительно замедляются. В некоторых случаях были показаны частоты до 2000 МГц; возможно, что 1800 МГц также будет использоваться для внутреннего использования.
  • A10-6700 состоит из двух модулей по два ядра в каждом. Если, например, два ядра простаивают, а два ядра заняты и ускоряются, поведение системы будет различным в зависимости от того, находятся ли занятые ядра в одном модуле или нет.
    • Ускорение модуля требует больших затрат энергии, чем ускорение ядра.
    • Кэш L2 назначается для каждого модуля.
  • Разница между рассеиваемой мощностью двух ядер, ускоряющихся на одном и том же модуле, и на разных модулях была определена заменой stress --cpu 2 (что всегда приводило к распределению между двумя модулями) на набор задач -c 0 напряжение - процессор 1 и набор задач -c 1 напряжение - процессор 1 .
  • Похоже, что у A10-6700 общий предел рассеиваемой мощности для APU (92 Вт вместе с другими компонентами) с крошечным битом, зарезервированным только для графического процессора (3 Вт). С radeon он позволяет получать больше в течение короткого периода и очень плавно снижать до максимума, в то время как с fglrx было замечено, что эти пределы превышаются более значительно и рассеиваемая мощность затем резко снижается.
  • Хотя многие люди утверждают, что задержка доступности Kaveri предназначается AMD, потому что это убьет их текущие APU, я прошу не согласиться. Richland A10 продемонстрировал отличное управление питанием, а Kaveri не может конкурировать с его низким энергопотреблением в состоянии покоя (сложность микросхемы Kaveri почти вдвое выше, чем у Richland, поэтому потребуется еще один или два этапа разработки).

Общий вывод

  • Включение температуры в логику Turbo Core (как сообщается для шага Trinity -> Richland) кажется логичным и работает хорошо, что можно увидеть по уменьшению рассеивания мощности в BIOS и Загрузчик со временем.
  • Для сценария cosole / server A10-6700 поддерживает 4 ядра @ 3700MHz (3800MHz с Turbo Core) в течение длительного времени, по крайней мере, с драйвером radeon . Вероятно, не так много шансов сохранить этот уровень производительности, когда графический процессор получит некоторую работу.
  • Казалось бы, TDP 65 Вт может быть постоянно немного превышен при полной нагрузке, но это трудно сказать, так как блок питания имеет более низкий КПД при 30 Вт. Поскольку есть четкие указания на то, что температура учитывается (пиковая мощность рассеивания почти 110 Вт наблюдалась до того, как она начала снижаться до 90 Вт, а также в течение некоторого времени сообщалось о 2 ядрах на 4300 МГц), инвестиции в охлаждение APU могут быть отличная идея. Однако материнские платы с ограничением TDP 65 Вт смогут обеспечивать только такой большой ток, поэтому APU определенно будет жестко ограничивать.
  • Если вы собираетесь использовать APU Richland для вычислений под Linux, вы определенно захотите использовать исправленный драйвер radeon (если вы не столкнетесь с нестабильностью, особенно в сочетании с включением динамического управления питанием ). В противном случае вы не получите полной отдачи.
  • Как ни странно, кажется, что лучше всего было бы включить Turbo Core и Cool'n'Quiet в BIOS, но затем выбрать регулятор масштабирования производительности - по крайней мере, если ваш APU ведет себя как тот, который протестирован здесь.У вас будет такое же энергопотребление, как и в случае ondemand , но более быстрое масштабирование частоты и меньшие накладные расходы ядра для принятия решения о масштабировании.

Благодарности

Особая благодарность Алексу Дойчеру, который значительно подтолкнул меня в правильном направлении на bugzilla.kernel.org .

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

13
27.01.2020, 19:58

Теги

Похожие вопросы