Моя мета - створити міні-сервер (не HTPC) з низьким енергоспоживанням в режимі очікування, але при цьому приємні показники при використанні. Основна увага приділяється більшій безпеці даних, ніж доступності. Іншими словами: якісні деталі, але надмірність лише для зберігання.

Не вважаючи себе упередженим, після деяких досліджень я відчув, що деякі настільні пристрої AMD пропонують хорошу цінність.

Залишилися питання:

• Чи знизить спокійний стан GPU споживання енергії та розкриє ресурси для процесора?
• Чи приведуть Cool'n'Quiet і Turbo Core до передбачуваного низького енергоспоживання в режимі очікування, але продуктивність під навантаженням?
• Чи підтримає Linux цей сценарій за призначенням? Досить мало запитань та обговорень на форумі свідчать про те, що це не обов'язково.

[Редагувати: висновки щодо вибору процесора]

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

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

Див. [Тягнути] radeon drm-fixes-3.16 .

Однак щодо Debian на базі 3.16, дефолти, здається, не працюють (поки що?), А параметр завантаження не працює. Див. Як настроїти систему Debian (зосередити увагу на 2D або консолі / сервері) з AMD Turbo Core APU для максимальної енергії та ефективності обчислень?

[Редагувати: незабаром у безкоштовного драйвера Radeon з'явиться bapmпараметр]

Оскільки в нижньому рядку нижче є використання виправленої версії безкоштовного radeonдрайвера з вашим APU, щоб підтримувати Turbo Core та отримувати максимальну користь від нього (за винятком 3D графіки, якщо це можливо) (включення bapmможе призвести до нестабільності в деяких конфігураціях ), це чудова новина, що у майбутніх версіях radeon буде параметр, який дозволяє включити bapm .

[Оригінальна публікація випливає]

AMD A10-6700 (Річленд) APU Досвід

Вибір процесора

Першим моїм ПК був 486DX2-66, встановлений з десятків 3,5-дюймових дискети, що містять джерела програм Slackware. З моменту цього, багато чого змінилося, і багато галузей зараз, здається, перебувають у фазі, коли вони все ще збільшують кількість варіантів продукції.

Ця обставина та деякі невдалі рішення AMD у недавньому минулому не полегшили мені вибір платформи для міні-сервера. Але нарешті я вирішив, що A10-6700 буде хорошим вибором:

• Кілька відгуків показали, що (досі широко недоступний) Kaveri буде споживати більше енергії в режимі очікування, ніж Richland або Trinity
• Перевага Richland A10-6700 над Trinity A10-5700 здається значною: нижня нижча та висока найвища частота, більш дрібнозерниста Turbo Core (враховуючи також температуру - досить перевагу, коли GPU буде простоювати)
• Кажуть, що графічний процесор A10-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.

Початкова спільна пам'ять для GPU була встановлена ​​на 32 М у BIOS UEFI. Також бортовий GPU було обрано як основний, і IOMMU було включено.

Жодна X або інша графічна система не була встановлена ​​або налаштована. Вихід відео був обмежений у консольному режимі.

Основи

Є кілька речей, які потрібно знати.

• Хоча рішення про Cool'n'Quiet приймається програмним забезпеченням поза процесорами, Turbo Core - це рішення, яке приймається автономно додатковим мікроконтролером на APU (або процесорі).
• Багато інструменти, а також /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(драйвер GPU ядра) та простий спосіб виправлення radeon.

Тестовий випадок 1.1: увімкнено BIOS TC - CnQ on / Linux OnDemand - Boost

Налаштування Turbo Core UEFI BIOS ............................ Увімкнено
Налаштування UEFI BIOS Cool'n'Quiet .......................... Увімкнено
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / пристрої / system / cpu / cpu * / cpufreq / skaliranje_governor ... ondemand 

"частота інформації cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Спостерігається "/ proc / cpuinfo" діапазон МГц процесора ... 1800 - 3700
Спостережений діапазон частот "монітор cpupower" ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... рівень потужності 0

Навантаження | Основні частоти
--------------- + -----------
стрес --cpu 1 | 1 х 3700
стрес --cpu 2 | 2 х 3700
стрес --cpu 3 | 3 х 3700
напруга --cpu 4 | 4 х 3700

Тестовий випадок 1.2: BIOS TC увімкнено - CnQ on / Linux Performance - Boost

Налаштування Turbo Core UEFI BIOS ............................ Увімкнено
Налаштування UEFI BIOS Cool'n'Quiet .......................... Увімкнено
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / пристрої / system / cpu / cpu * / cpufreq / skaliranje_governor ... продуктивність 

"частота інформації cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Спостережений "/ proc / cpuinfo" діапазон МГц процесора ... 3700
Спостережений діапазон частот "монітор cpupower" ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... рівень потужності 0

Навантаження | Основні частоти
--------------- + -----------
стрес --cpu 1 | 1 х 3700
стрес --cpu 2 | 2 х 3700
стрес --cpu 3 | 3 х 3700
напруга --cpu 4 | 4 х 3700

Підсумок групи тестових випадків 1

Форсує на основі Turbo Core є в даному випадку неможливо , оскільки в даний момент драйвер відключає прапор з - за проблеми зі стабільністю в деяких сценаріях . Тому подальше тестування було пропущено.radeonbapm

Тестовий випадок, група 2: Linux + патч-патч із робочою потужністю

Для того щоб 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

Налаштування Turbo Core UEFI BIOS ............................ Увімкнено
Налаштування UEFI BIOS Cool'n'Quiet .......................... Увімкнено
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / пристрої / system / cpu / cpu * / cpufreq / skaliranje_governor ... ondemand 

"частота інформації cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Спостерігається "/ proc / cpuinfo" діапазон МГц процесора ... 1800 - 3700
Спостережений діапазон частот "монітор cpupower" ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... рівень потужності 0

Навантаження | Основні частоти
--------------- + -----------------
стрес --cpu 1 | 1 х 4300
стрес --cpu 2 | 2 х 4200 .. 4100
стрес --cpu 3 | 3 х 4100 .. 3900
напруга --cpu 4 | 4 х 4000 .. 3800

Тестовий випадок 2.2: Увімкнено BIOS TC - Ввімкнення CnQ / Linux - Посилення

Налаштування Turbo Core UEFI BIOS ............................ Увімкнено
Налаштування UEFI BIOS Cool'n'Quiet .......................... Увімкнено
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / пристрої / system / cpu / cpu * / cpufreq / skaliranje_governor ... performace

"частота інформації cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Спостережений "/ proc / cpuinfo" діапазон МГц процесора ... 3700
Спостережений діапазон частот "монітор cpupower" ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... рівень потужності 0

Навантаження | Основні частоти
--------------- + -----------------
стрес --cpu 1 | 1 х 4300
стрес --cpu 2 | 2 х 4200 .. 4100
стрес --cpu 3 | 3 х 4100 .. 3900
напруга --cpu 4 | 4 х 4000 .. 3800

Тестовий випадок 2.3: Увімкнено BIOS TC - CnQ on / Linux OnDemand - Без підвищення

Налаштування Turbo Core UEFI BIOS ............................ Увімкнено
Налаштування UEFI BIOS Cool'n'Quiet .......................... Увімкнено
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / пристрої / system / cpu / cpu * / cpufreq / skaliranje_governor ... ondemand

"частота інформації cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Спостерігається "/ proc / cpuinfo" діапазон МГц процесора ... 1800 - 3700
Спостережений діапазон частот "монітор cpupower" ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... рівень потужності 1

Навантаження | Основні частоти
--------------- + -----------
стрес --cpu 1 | 1 х 3700
стрес --cpu 2 | 2 х 3700
стрес --cpu 3 | 3 х 3700
напруга --cpu 4 | 4 х 3700

Тестовий випадок 2.4: Увімкнено BIOS TC - Ввімкнення CnQ / Linux - Не збільшується

Налаштування Turbo Core UEFI BIOS ............................ Увімкнено
Налаштування UEFI BIOS Cool'n'Quiet .......................... Увімкнено
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / пристрої / system / cpu / cpu * / cpufreq / skaliranje_governor ... performace

"частота інформації cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Спостережений "/ proc / cpuinfo" діапазон МГц процесора ... 3700
Спостережений діапазон частот "монітор cpupower" ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... рівень потужності 1

Навантаження | Основні частоти
--------------- + -----------
стрес --cpu 1 | 1 х 3700
стрес --cpu 2 | 2 х 3700
стрес --cpu 3 | 3 х 3700
напруга --cpu 4 | 4 х 3700

Тестовий випадок 2.5: вимкнено TC для BIOS - CnQ увімкнено / Linux OnDemand - Boost

Налаштування Turbo Core UEFI BIOS ............................ Вимкнено
Налаштування UEFI BIOS Cool'n'Quiet .......................... Увімкнено
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / пристрої / system / cpu / cpu * / cpufreq / skaliranje_governor ... ondemand 

"частота інформації cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Спостерігається "/ proc / cpuinfo" діапазон МГц процесора ... 1800 - 3700
Спостережений діапазон частот "монітор cpupower" ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... рівень потужності 0

Іншими словами, якщо Turbo Core відключений в BIOS, виправлений radeonне буде його включати.

Тестовий випадок 2.6: увімкнено BIOS TC - вимкнено CnQ / Linux n / a

Налаштування Turbo Core UEFI BIOS ............................ Увімкнено
Налаштування UEFI BIOS Cool'n'Quiet .......................... Вимкнено
/ sys / devices / system / cpu / cpufreq / boost ................... n / a
/ sys / пристрої / system / cpu / cpu * / cpufreq / skaliranje_governor ... n / a

"частота інформації cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Спостережений "/ proc / cpuinfo" діапазон МГц процесора ... 3700
Спостережений діапазон частот "монітор cpupower" ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... рівень потужності 0

Навантаження | Основні частоти
--------------- + -----------------
стрес --cpu 1 | 1 х 4300
стрес --cpu 2 | 2 х 4100 .. 4000
стрес --cpu 3 | 3 х 4000 .. 3800
напруга --cpu 4 | 4 х 3900 .. 3700

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

Резюме тестової групи 2

З виправленим radeonдрайвером працює Turbo Core. Ніякої нестабільності (що є причиною того, що bapmака Turbo Core там відключений) досі не було помічено.

Група тестових випадків 3: Linux + fglrx (каталізатор)

Я почав із нової установки Ubuntu (14.04 Server, ядро ​​3.13), яку я вважаю порівнянною з Arch Linux (інсталятор 2014.08.01, ядро ​​3.15.7) через наявність acpi_cpufreq(масштабування процесора ядра) та radeon(драйвер GPU ядра) ). Причиною переходу на 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 Вт,: radeon30 Вт). Але Turbo Core працює відразу.

Тестовий випадок 3.1: Ввімкнено BIOS TC - CnQ on / Linux OnDemand - Boost

Налаштування Turbo Core UEFI BIOS ............................ Увімкнено
Налаштування UEFI BIOS Cool'n'Quiet .......................... Увімкнено
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / пристрої / system / cpu / cpu * / cpufreq / skaliranje_governor ... ondemand 

"частота інформації cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Спостерігається "/ proc / cpuinfo" діапазон МГц процесора ... 1800 - 3700
Спостережений діапазон частот "монітор cpupower" ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... n / a

Навантаження | Основні частоти
--------------- + ----------------------------
стрес --cpu 1 | 1 х 4300
стрес --cpu 2 | 2 х 4200 .. 3900 (основний чгг)
стрес --cpu 3 | 3 х 4100 .. 3700
напруга --cpu 4 | 4 х 4000 .. 3600

fglrxПоведінка, безумовно , цікаво. Коли для будь-якого з тестових випадків у будь-якій групі тестових випадків викликали "стрес --cpu 2", два завантажені ядра завжди були розташовані на окремих модулях. Але з fglrxраптовим перерозподілом сталося таке, що використовувався один модуль (що економить досить багато енергії, див. Нижче). Через деякий час завантажене ядро ​​перемістилося назад до іншого модуля. Цього не бачили radeon. Чи може це fglrxманіпулювати спорідненість процесів?

Резюме групи тестових груп 3

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

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

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

Підсумок споживання електроенергії

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

Система @State / -> Дельта переходу | Розсіювання потужності системи
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86W
  @Bootloader | @ 108 .. 89W
  @Ubuntu Інсталятор не працює | @ 40W
  @Linux radeon Idle попит | @ 30 Вт
  Продуктивність @Linux radeon Idle | @ 30 Вт
  @Linux fglrx Простий попит | @ 40W
  1 Модуль 1800 -> 3700 | + 13 Вт
  1 Модуль 1800 -> 4300 | + 25 Вт
  1 Core 1800 -> 3700 | + 5 Вт
  1 Core 1800 -> 4300 | + 10 Вт
  "Radeon" Video Out -> Вимкнути | - 2Вт
  'fglrx "Відеозапис -> затемнення | + - 0W
  @Linux radeon Максимум | @ 103 .. 89W
  @Linux fglrx Максимум | @ 105 .. 92Вт

• Для Turbo Core (принаймні, з APU Річленду), здається, більше, ніж очікувалося: Немає помітної різниці в розсіюванні потужності, коли встановлений "масштабний" регулятор на місці, порівняно з тим, коли встановлений "керуючий" регулятор. Althouth /proc/cpuinfoзавжди буде повідомляти 37000 МГц під управлінням продуктивністю, cpupower monitorвиявить, що ядра насправді сповільнюються. У деяких випадках були показані частоти до 2000 МГц; можливо, що 1800 МГц буде використовуватися і внутрішньо.
• A10-6700 складається з двох модулів з двома ядрами кожен. Якщо, наприклад, два ядра в режимі очікування та два ядра зайняті та прискорені, поведінка системи буде відрізнятися залежно від того, чи є зайняті ядра в одному модулі чи ні.
  • Прискорення модуля більш енергоємне, ніж прискорення ядра.
  • Кеш L2 призначений для кожного модуля.
• Різниця між розсіюванням потужності двох ядер, що прискорюються на одному модулі проти різних модулів, визначалася шляхом заміни stress --cpu 2(що завжди призводило до розподілу між двома модулями) на .taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• Здається, A10-6700 має обмеження сумарного розсіювання потужності для APU (92 Вт разом з іншими компонентами) з невеликим бітом, зарезервованим лише для GPU (3 Вт). З radeon, це дозволить отримати більше протягом короткого періоду і звести до максимуму дуже плавно, в той час як з fglrx, було помічено, що ці межі перевищуються значно, і розсіювання потужності потім різко зменшується.
• Хоча багато людей стверджують, що затримка доступності Kaveri призначена AMD, оскільки це знищить їх нинішні APU, я прошу відрізнятись. Річленд A10 продемонстрував відмінне енергоспоживання, і Kaveri не може конкурувати зі своїм низьким енергоспоживанням в режимі простою (складність чіпів Kaveri майже вдвічі більша за потужність Річленда, тому знадобиться ще один або два кроки розвитку).

Загальний висновок

• Включення температури в логіку Turbo Core (як повідомляється для кроку Trinity -> Richland), здається, має сенс і, здається, працює добре, як це видно за рахунок зменшення розсіювання потужних частот у BIOS та Bootloader з часом.
• Для сценарію cosole / server A10-6700 підтримує 4 ядра при 3700 МГц (3800 МГц з Turbo Core) на тривалий термін, принаймні, з radeonдрайвером. Напевно, не так вже й багато шансів зберегти цей рівень продуктивності, коли GPU отримає певну роботу.
• Здавалося б, TDP 65W можна постійно перевищити при повному навантаженні, але важко сказати, оскільки джерело живлення має менший ККД при 30 Вт. Оскільки є чіткі вказівки на врахування температури (пікове розсіювання потужності майже 110 Вт спостерігалося до того, як воно почало знижуватися до 90 Вт, а також протягом деякого часу повідомлялося про 2 ядра на 4300 МГц), інвестування в охолодження APU може бути гарна ідея. Однак плати з обмеженою потужністю 65 Вт TDP зможуть подавати тільки стільки струму, тож, безумовно, буде жорсткий ліміт, накладений APU.
• Якщо ви плануєте використовувати APU Richland для обчислень під Linux, ви, безумовно, хочете використовувати виправлений radeonдрайвер (якщо ви не стикаєтеся з нестабільністю, зокрема в поєднанні з включенням системи Dynamic Power Management). Інакше ви не отримаєте повного значення.
• Як не дивно, здається, що найкращим налаштуванням було б включити як Turbo Core, так і Cool'n'Quiet в BIOS, але потім вибрати performanceрегулятор масштабування - принаймні, якщо ваш APU веде себе як тестований тут. Ви будете мати таке ж енергоспоживання, що і для ondemandшвидшого масштабування частоти та менше накладних витрат на ядро, щоб прийняти рішення щодо масштабування.

Подяка

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

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