Mon objectif est de mettre en place un mini serveur (pas HTPC) à faible consommation d'énergie en mode veille, tout en offrant de belles performances lors de son utilisation. L'accent est davantage mis sur la sécurité des données que sur la disponibilité. En d'autres termes: pièces de qualité, mais redondance uniquement pour le stockage.

Ne me considérant pas comme biaisé, après quelques recherches, j'ai senti que certains APU de bureau AMD offriraient une bonne valeur.

Les questions restantes sont:

• L'état inactif du GPU réduira-t-il la consommation d'énergie et libérera-t-il les ressources du processeur?
• Cool'n'Quiet et Turbo Core entraîneront-ils la faible consommation d'énergie prévue en mode veille mais des performances sous charge?
• Linux prendra-t-il en charge ce scénario comme prévu? De nombreuses questions et discussions sur le forum semblent suggérer que ce n'est pas nécessairement le cas.

[Modifier: réflexions finales concernant le choix du processeur]

• AMD vs AMD:
  • Richland fait un bien meilleur travail que Trinity ici.
  • Kaveri ne peut pas rivaliser avec la dissipation de puissance en mode veille de Richland (du moins pour l'instant).
  • Le GPU de l'A10-6700 est peut-être surévalué, mais c'est un peu triste qu'il ne soit pas beaucoup utilisé. Certains algorithmes peuvent être en mesure de déployer sa puissance de calcul. Cependant, je ne sais pas comment cela affectera la consommation d'énergie du processeur.
  • Je soupçonne l'A10-6790K d'être le même processeur que l'A10-6700 avec juste un ensemble de paramètres différent pour les boosts Turbo Core. Si cela est vrai, l'A10-6790K pourra augmenter plus longtemps et / ou fournir des fréquences plus élevées à long terme en raison de son TDP plus élevé. Mais vous aurez besoin d'un ventilateur de processeur différent pour cela (pensez à l'espace et à la température / durée de vie).
• AMD A10-6700 contre Intel Core i3-3220:
  • L'A10-6700 a beaucoup plus de puissance GPU, qui n'est pas utilisée ici.
  • Le i3-3220 a une dissipation de puissance en mode ralenti inférieure.
  • Alors que dans les tests de référence typiques, l'i3-3220 est plus rapide pour les calculs, je ne vois pas comment ses deux cœurs hyper-threading seraient capables de gérer les requêtes parallèles (par exemple, vers une base de données avec des interfaces Web) aussi rapidement que quatre cœurs complets (au moins en supposant une mise en cache sérieuse). N'a pas trouvé de repères sérieux, cependant - Seulement quelques indications.

[Modifier: Le bapmparamètre du pilote gratuit radeon est défini par défaut pour les systèmes Kaveri, Kabini et Trinity, Richland de bureau à partir de Linux 3.16]

Voir [pull] radeon drm-fixes-3.16 .

Cependant, concernant Debian basé sur 3.16, les valeurs par défaut ne semblent pas (encore?) Fonctionner, contrairement au paramètre de démarrage. Voir Comment configurer un système Debian (en se concentrant sur la 2D ou la console / serveur) avec un APU AMD Turbo Core pour une efficacité énergétique et informatique maximale?

[Edit: Le pilote gratuit de radeon aura bientôt un bapmparamètre]

Étant donné radeonque l'essentiel de ce qui suit est d'utiliser une version corrigée du pilote gratuit avec votre APU pour prendre en charge Turbo Core et en tirer le meilleur parti (sauf les graphiques 3D), si vous le pouvez (l'activation bapmpeut entraîner des instabilités dans certaines configurations ), c'est une excellente nouvelle que les futures versions de radeon auront un paramètre pour activer bapm .

[Le message d'origine suit]

Expérience APU AMD A10-6700 (Richland)

Choix du processeur

Mon premier PC était un 486DX2-66 installé à partir de dizaines de disquettes 3,5 "contenant des packages source Slackware. Sice alors, beaucoup de choses ont changé, et beaucoup d'industries semblent actuellement être dans la phase où elles continuent d'augmenter le nombre de variantes de produits.

Cette circonstance et certaines des décisions malheureuses d'AMD dans le passé récent ne m'ont pas permis de décider plus facilement d'une plate-forme pour un mini-serveur. Mais finalement, j'ai décidé que l'A10-6700 serait un bon choix:

• Plusieurs critiques ont montré qu'un Kaveri (encore largement indisponible) consommera plus d'énergie en mode veille qu'un Richland ou un Trinity
• L'avantage du Richland A10-6700 par rapport au Trinity A10-5700 semble être significatif: la fréquence la plus basse et la plus élevée les plus basses, le Turbo Core à grains plus fins (compte tenu également de la température - tout un avantage lorsque le GPU sera inactif)
• Le GPU de l'A10-6700 serait surévalué (dénomination marketing) et le prix de l'APU semble juste

Autres composants et configuration

Malgré les innombrables processeurs parmi lesquels choisir, il n'y a pas beaucoup de cartes Mini-ITX disponibles. L'ASRock FM2A78M-ITX + semble être un choix raisonnable. Le test a été effectué avec le firmware V1.30 (aucune mise à jour disponible au moment où j'écris ceci).

Seuls 80% de la puissance nominale d'une alimentation doivent être consommés. D'un autre côté, beaucoup ne fonctionnent pas efficacement sous une charge de 50%. Il est très difficile de trouver une alimentation électrique économe en énergie pour un système avec une plage de dissipation de puissance estimée de 35W à 120W. J'ai effectué ces tests avec un Seasonic G360 80+ Gold car il surpasse la plupart des concurrents en termes d'efficacité à faibles charges.

Deux RAM DDR3-1866 de 8 Go (configurées en tant que telles - ce qui fait une différence par rapport à 1333), un lecteur SSD et un ventilateur CPU de qualité contrôlée PWM faisaient également partie de la configuration de test.

Les mesures ont été effectuées en utilisant un AVM Fritz! DECT 200 qui a été rapporté pour effectuer des mesures précises. Pourtant, la plausibilité a été validée à l'aide d'un ancien appareil sans nom. Aucune incohérence n'a pu être identifiée. La dissipation de puissance du système mesurée inclura l'efficacité réduite de l'alimentation pour des charges plus faibles.

Un écran [W] QHD a été connecté via HDMI.

La mémoire partagée initiale du GPU a été définie sur 32 Mo dans le BIOS UEFI. En outre, le GPU intégré a été sélectionné en tant que principal et IOMMU a été activé.

Aucun X ou autre système graphique n'a été installé ou configuré. La sortie vidéo était limitée au mode console.

Les bases

Il y a quelques choses à savoir.

• Alors que la décision concernant Cool'n'Quiet est prise par un logiciel en dehors des processeurs, Turbo Core est une décision prise de manière autonome par un microcontrôleur supplémentaire sur l'APU (ou CPU).
• De nombreux outils, ainsi que /procet /syslieux ne signalent pas l' activité Turbo Core. cpufreq-aperf, cpupower frequency-infoEt cpupower monitorfaire, mais seulement après modprobe msr.

Groupe de cas de test 1: Linux + radeon

J'ai commencé avec Arch Linux (programme d'installation 2014.08.01, noyau 3.15.7). Le facteur clé ici est la présence de acpi_cpufreq(mise à l'échelle du processeur du noyau) et radeon(pilote GPU du noyau) et le moyen facile de corriger radeon.

Cas de test 1.1: BIOS TC activé - CnQ activé / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting ............................ Activé
UEFI BIOS Cool'n'Quiet Setting .......................... Enabled
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower fréquence-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Gamme de MHz cpu "/ proc / cpuinfo" observée ... 1800 - 3700
Fréquence de "moniteur de puissance cp" observée ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... niveau de puissance 0

Charge | Freqs de base
--------------- + -----------
contrainte --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Cas de test 1.2: BIOS TC activé - CnQ activé / Performances Linux - Boost

UEFI BIOS Turbo Core Setting ............................ Activé
UEFI BIOS Cool'n'Quiet Setting .......................... Enabled
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performance 

"cpupower fréquence-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Plage de MHz cpu "/ proc / cpuinfo" observée ... 3700
Plage de fréquences observées du "moniteur de puissance" ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... niveau de puissance 0

Charge | Freqs de base
--------------- + -----------
contrainte --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Résumé du groupe de cas de test 1

Les boosts basés sur Turbo Core sont impossibles dans ce scénario car le radeonpilote désactive actuellement l' bapmindicateur en raison de problèmes de stabilité dans certains scénarios . Par conséquent, d'autres tests ont été ignorés.

Test Case Group 2: Linux + radeon patché bapm

Afin de permettre bapm, j'ai commencé avec une nouvelle Arch Linux (installation 01/08/2014, noyau 3.15.7), m'a reçu le core linuxpaquet via ABS(3.15.8), sous la direction du PKGBUILDà l' utilisation pkgbase=linux-tc, tiré les sources avec makepkg --nobuild, changé pi->enable_bapm = true;en trinity_dpm_init()dans src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.cet compilé avec makepkg --noextract. Ensuite, je l'ai installé ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzet pacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz) et mis à jour GRUB( grub-mkconfig -o /boot/grub/grub.cfgmais, bien sûr, YMMV).

En conséquence, j'ai eu le choix de démarrer linuxou linux-tc, et les tests suivants se réfèrent à ce dernier.

Cas de test 2.1: BIOS TC activé - CnQ activé / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting ............................ Activé
UEFI BIOS Cool'n'Quiet Setting .......................... Enabled
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower fréquence-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Gamme de MHz cpu "/ proc / cpuinfo" observée ... 1800 - 3700
Fréquence de "moniteur de puissance cp" observée ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... niveau de puissance 0

Charge | Freqs de base
--------------- + -----------------
contrainte --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

Cas de test 2.2: BIOS TC activé - Performances CnQ / Linux - Boost

UEFI BIOS Turbo Core Setting ............................ Activé
UEFI BIOS Cool'n'Quiet Setting .......................... Enabled
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"cpupower fréquence-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Plage de MHz cpu "/ proc / cpuinfo" observée ... 3700
Plage de fréquences observées du "moniteur de puissance" ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... niveau de puissance 0

Charge | Freqs de base
--------------- + -----------------
contrainte --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

Cas de test 2.3: BIOS TC activé - CnQ activé / Linux OnDemand - Pas de boost

UEFI BIOS Turbo Core Setting ............................ Activé
UEFI BIOS Cool'n'Quiet Setting .......................... Enabled
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand

"cpupower fréquence-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Gamme de MHz cpu "/ proc / cpuinfo" observée ... 1800 - 3700
Fréquence de "moniteur de puissance cp" observée ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... niveau de puissance 1

Charge | Freqs de base
--------------- + -----------
contrainte --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Cas de test 2.4: BIOS TC activé - CnQ activé / Performances Linux - Pas de boost

UEFI BIOS Turbo Core Setting ............................ Activé
UEFI BIOS Cool'n'Quiet Setting .......................... Enabled
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"cpupower fréquence-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Plage de MHz cpu "/ proc / cpuinfo" observée ... 3700
Plage de fréquences observées du "moniteur de puissance" ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... niveau de puissance 1

Charge | Freqs de base
--------------- + -----------
contrainte --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Cas de test 2.5: BIOS TC désactivé - CnQ activé / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting ............................ Désactivé
UEFI BIOS Cool'n'Quiet Setting .......................... Enabled
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower fréquence-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Gamme de MHz cpu "/ proc / cpuinfo" observée ... 1800 - 3700
Fréquence de "moniteur de puissance cp" observée ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... niveau de puissance 0

En d'autres termes, si Turbo Core est désactivé dans le BIOS, le patch radeonne l'activera pas.

Cas de test 2.6: BIOS TC activé - CnQ désactivé / Linux n / a

UEFI BIOS Turbo Core Setting ............................ Activé
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 fréquence-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Plage de MHz cpu "/ proc / cpuinfo" observée ... 3700
Plage de fréquences observées du "moniteur de puissance" ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... niveau de puissance 0

Charge | Freqs de base
--------------- + -----------------
contrainte --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

Avec Cool'n'Qiet désactivé, le noyau Linux n'offrira aucun choix de gouverneur et supposera (à tort) que les cœurs fonctionnent à une fréquence fixe. Fait intéressant, les fréquences Turbo Core résultantes sont les pires de toutes les combinaisons testées dans le groupe de cas de test 2.

Résumé du groupe de cas de test 2

Avec le radeonpilote patché , Turbo Core fonctionne. Aucune instabilité (qui est la raison pour laquelle bapmaka Turbo Core est désactivé là-bas) n'a été constatée jusqu'à présent.

Groupe de cas de test 3: Linux + fglrx (catalyseur)

J'ai commencé avec une nouvelle installation d'Ubuntu (serveur 14.04, noyau 3.13), que je vois comme comparable à Arch Linux (installateur 2014.08.01, noyau 3.15.7) en raison de la présence de acpi_cpufreq(mise à l'échelle du processeur du noyau) et radeon(pilote GPU du noyau ). La raison de passer à Ubuntu est l'installation facile de fglrx. J'ai validé la consommation d'énergie et le comportement avec la nouvelle installation, qui utilise radeon.

J'ai installé à fglrxpartir de la ligne de commande ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) et redémarré le système. Le changement de radeonà fglrxest immédiatement évident à la fois en ce qui concerne l'apparence de la console ( fglrx: 128 x 48,: radeonbeaucoup plus élevé) et la consommation d'énergie en mode veille ( fglrx: 40W,: radeon30W). Mais Turbo Core fonctionne tout de suite.

Cas de test 3.1: BIOS TC activé - CnQ activé / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting ............................ Activé
UEFI BIOS Cool'n'Quiet Setting .......................... Enabled
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower fréquence-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Gamme de MHz cpu "/ proc / cpuinfo" observée ... 1800 - 3700
Fréquence de "moniteur de puissance cp" observée ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... n / a

Charge | Freqs de base
--------------- + ----------------------------
contrainte --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 3900 (noyau chg)
stress --cpu 3 | 3 x 4100 .. 3700
stress --cpu 4 | 4 x 4000 .. 3600

Le fglrxcomportement est définitivement intéressant. Lorsque «stress --cpu 2» était appelé pour l'un des cas tes dans n'importe quel groupe de cas de test, les deux cœurs chargés étaient toujours situés sur des modules séparés. Mais avec fglrx, une réallocation soudaine s'est produite, de sorte qu'un seul module a été utilisé (ce qui permet d'économiser un peu d'énergie, voir ci-dessous). Après un certain temps, le noyau chargé est revenu à l'autre module. Cela n'a pas été vu avec radeon. Se pourrait-il que cela fglrxmanipule l'affinité centrale des processus?

Résumé du groupe de cas de test 3

L'avantage fglrxest qu'il permet le Turbo Core immédiatement, sans avoir besoin de le patcher.

Parce que fglrxgaspille 10 à 12 W pour le GPU dans notre scénario sur une puce avec 65 W TDP, les résultats globaux concernant les vitesses de base disponibles ne sont pas impressionnants. Par conséquent, aucun autre test n'a été effectué.

D'un point de vue technique également, le comportement de fglrxsemble être un peu triste. Réallouer l'un des deux cœurs occupés à l'autre module pour maintenir une fréquence plus élevée peut ou non être une bonne idée, car avant cette étape, les deux cœurs avaient leur propre cache L2, tandis qu'après, ils doivent en partager un. La question de savoir fglrxsi des mesures (telles que les échecs de cache) pour appuyer sa décision devra être clarifiée séparément, mais il existe d'autres rapports sur son comportement brutal .

Résumé de la consommation d'énergie

Certaines des valeurs delta dans le tableau suivant s'aggravent légèrement lorsque la température augmente; on pourrait dire que le ventilateur contrôlé par PWM et la puce y jouent tous deux un rôle.

System @State / -> Transition Delta | Dissipation de puissance du système
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86W
  @Bootloader | @ 108 .. 89W
  @Ubuntu Installer Idle | @ 40W
  @Linux radeon Idle ondemand | @ 30W
  @Linux radeon Performances inactives | @ 30W
  @Linux fglrx Idle ondemand | @ 40W
  1 module 1800 -> 3700 | + 13W
  1 module 1800 -> 4300 | + 25W
  1 cœur 1800 -> 3700 | + 5W
  1 cœur 1800 -> 4300 | + 10W
  Sortie vidéo "radeon" -> Désactiver | - 2W
  Sortie vidéo 'fglrx "-> Assombrir | + - 0W
  @Linux radeon Maximum | @ 103 .. 89W
  @Linux fglrx Maximum | @ 105 .. 92W

• Il semble y avoir plus de Turbo Core (au moins avec les APU Richland) que prévu: il n'y a pas de différence notable dans la dissipation de puissance lorsque le gouverneur de mise à l'échelle "à la demande" est en place par rapport au moment où le gouverneur "performance" est en place. Althouth /proc/cpuinforapportera toujours 37 000 MHz sous le gouverneur de performances, cpupower monitorrévélera que les cœurs ralentissent réellement. Dans certains cas, des fréquences aussi basses que 2000 MHz ont été montrées; il est possible que 1800 MHz soit également utilisé en interne.
• L'A10-6700 se compose de deux modules avec deux cœurs chacun. Si, par exemple, deux cœurs sont inactifs et que deux cœurs sont occupés et accélérés, le comportement du système sera différent selon que les cœurs occupés sont situés sur le même module ou non.
  • L'accélération d'un module est plus énergivore que l'accélération d'un cœur.
  • Le cache L2 est attribué par module.
• La différence entre la dissipation de puissance de deux cœurs accélérant sur le même module vs sur des modules différents a été déterminée en remplaçant stress --cpu 2(ce qui a toujours conduit à une répartition entre les deux modules) par .taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• L'A10-6700 semble avoir une limite de dissipation de puissance totale pour l'APU (92 W avec les autres composants) avec un tout petit peu réservé au GPU seul (3 W). Avec radeon, il permettra plus pendant une courte période et se réduira au maximum très en douceur, tandis qu'avec fglrx, il a été observé que ces limites sont dépassées de manière plus significative et la dissipation de puissance est alors réduite brusquement.
• Alors que de nombreuses personnes affirment que le retard dans la disponibilité de Kaveri est prévu par AMD car cela tuerait leurs APU actuels, je vous prie de différer. Le Richland A10 a démontré une excellente gestion de l'alimentation et le Kaveri ne peut pas rivaliser avec sa faible consommation d'énergie au ralenti (la complexité des puces de Kaveri est presque le double de celle de Richland, donc il faudra encore une ou deux étapes de développement).

Conclusion générale

• L'inclusion de la température dans la logique Turbo Core (comme indiqué pour l'étape Trinity -> Richland) semble logique et semble bien fonctionner, comme en témoigne la réduction de la dissipation pwoer dans le BIOS et Bootloader au fil du temps.
• Pour le scénario cosole / serveur, l'A10-6700 prend en charge 4 cœurs à 3700 MHz (3800 MHz avec Turbo Core) à long terme, au moins avec le radeonpilote. Il n'y a probablement pas beaucoup de chances de maintenir ce niveau de performances lorsque le GPU a du travail à faire.
• Il semblerait que le TDP de 65 W puisse être légèrement dépassé en permanence à pleine charge, mais c'est difficile à dire car l'alimentation a une efficacité inférieure à 30 W. Comme il y a des indications claires que la température est prise en compte (une dissipation de puissance maximale de près de 110 W a été observée avant de commencer à être réduite à 90 W, et également 2 cœurs à 4300 MHz ont été signalés pendant un certain temps), investir dans le refroidissement de l'APU peut être un bonne idée. Cependant, les cartes mères limitées à 65 W TDP ne pourront fournir qu'une telle quantité de courant, il y aura donc certainement une limite stricte imposée par l'APU.
• Si vous avez l'intention d'utiliser un APU Richland pour l'informatique sous Linux, vous voulez certainement utiliser un radeonpilote corrigé (si vous ne rencontrez pas d'instabilités - en particulier en conjonction avec l'activation de Dynamic Power Management). Sinon, vous n'obtiendrez pas la pleine valeur.
• Curieusement, il semble que la meilleure configuration serait d'activer à la fois Turbo Core et Cool'n'Quiet dans le BIOS, puis de choisir le performancegouverneur de mise à l' échelle - du moins si votre APU se comporte comme celui testé ici. Vous aurez la même consommation d'énergie qu'avec ondemandune mise à l'échelle de fréquence plus rapide et moins de surcharge du noyau pour prendre la décision de mise à l'échelle.

Remerciements

Des remerciements particuliers vont à Alex Deucher, qui m'a considérablement poussé dans la bonne direction sur bugzilla.kernel.org .

Je suis impressionné par la qualité du radeonpilote gratuit et je tiens à remercier toute l'équipe pour la maintenance de ce logiciel, qui semble avoir été soigneusement conçu. Si radeonelle ne se comportait pas comme elle le fait, ma décision en faveur de l'A10-6700 aurait été substantiellement erronée.