Mon processeur est AMD A6-9220 RADEON R4. J'utilise Ubuntu 16.04.1. Aucun pilote supplémentaire (propriétaire) disponible. Le processeur charge à la fois dans Chrome et Firefox, l'accélération matérielle est désactivée dans Chrome. Cela arrive quand je fais défiler la page principalement. Ou lorsque le navigateur est ouvert et que je fais autre chose (exécute d'autres tâches). Quelque chose qui ne va pas avec la navigation, je peux faire des tâches beaucoup plus lourdes sans une telle réaction du processeur (je peux regarder des vidéos HD, par exemple, depuis un disque dur sans que le chargement dépasse 23%). Comme la commande top
a montré que c'est principalement le processus Xorg
qui consomme beaucoup (50%).
Fait intéressant, j'ai une carte r300 (Mobility Radeon 200M) et un processeur beaucoup plus ancien dans mon ordinateur portable. Les deux étaient plus rapides que le cas de problème décrit ici et sans pics de processeur - jusqu'à ce que je mette à niveau mon système!
J'ai d'abord pensé que c'était le noyau, mais le passage à l'ancienne version de Xorg et de mesa a rendu tout plus rapide que jamais.
Je ne sais pas ce qui se passe, mais pour une raison quelconque, l'accélération GPU est devenue beaucoup plus gourmande en ressources processeur. Également dans mes performances, je vois surtout des mouvements de mémoire se dérouler la plupart du temps. Sur mon processeur à cœur unique qui utilise 100% du processeur, tout en revenant à un ancien mesa + xorg, je reçois au plus 25 à 40% et non dans les pilotes du processeur graphique. Quelque chose s'est clairement trompé à un moment donné.
Voir ici pour une analyse complète: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-AMD-linux/1099745-how-to-tell- si-un-pilote-est-gallium-ou-juste-mesa-lent-renderng-avec-radeon / .
Donc, vous m'avez curieux et j'ai décidé de profiler un peu Xorg. Note: Je n'ai pas de symboles de débogage installés (et vous ne pouvez pas leur faire confiance avec un code optimisé de toute façon) , donc le résultat que j'ai obtenu est un peu rare, mais néanmoins…
$ Sudo operf --pid=$(pgrep Xorg) # scroll youtube in chromium for a bit, then interrupt the command
^C
$ opreport -l | head -n 20
[warnings skipped]
CPU: AMD64 family12h, speed 1900 MHz (estimated)
Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name symbol name
6030 26.0351 r600_dri.so /usr/lib/dri/r600_dri.so
4717 20.3661 Xorg /usr/lib/Xorg
2616 11.2948 radeon /radeon
1135 4.9005 drm /drm
833 3.5966 libc-2.28.so _IO_vfscanf
793 3.4239 ttm /ttm
686 2.9619 radeon_drv.so /usr/lib/xorg/modules/drivers/radeon_drv.so
642 2.7719 libglamoregl.so /usr/lib/xorg/modules/libglamoregl.so
524 2.2624 libEGL_mesa.so.0.0.0 /usr/lib/libEGL_mesa.so.0.0.0
476 2.0552 libc-2.28.so arena_get2.part.4
465 2.0077 libGLdispatch.so.0.0.0 /usr/lib/libGLdispatch.so.0.0.0
397 1.7141 libglapi.so.0.0.0 /usr/lib/libglapi.so.0.0.0
345 1.4896 libc-2.28.so exec_comm
328 1.4162 libEGL.so.1.1.0 /usr/lib/libEGL.so.1.1.0
325 1.4032 libpixman-1.so.0.34.0 /usr/lib/libpixman-1.so.0.34.0
178 0.7685 libdrm.so.2.4.0 /usr/lib/libdrm.so.2.4.0
154 0.6649 libfb.so /usr/lib/xorg/modules/libfb.so
Ici encore plus de temps que dans Xorg lui-même est consacré à r600_dri, qui est un pilote graphique en espace utilisateur.
La conclusion que nous pouvons en tirer est que, pour réduire les frais de processeur, vous devez mettre à niveau vos pilotes, car il y a (comme dans tout projet, FWIW) de nouvelles optimisations sont en cours . Bien sûr, vous remarquez à peine quelques mois de travail, mais maan, la version 11.2.x de Mesa utilisée par votre 16.04 est antique !
À titre de comparaison, j'ai consulté Firefox sur youtube et y ai fait défiler un peu. Les résultats sont ci-dessous; un certain nombre d'échantillons est un peu plus gros, peut-être parce que j'ai fait défiler plus intensément, ou plus longtemps, ou les deux.
CPU: AMD64 family12h, speed 1900 MHz (estimated)
Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name symbol name
13128 41.2558 libc-2.28.so arena_get2.part.4
8628 27.1142 r600_dri.so /usr/lib/dri/r600_dri.so
2534 7.9633 Xorg /usr/lib/Xorg
1832 5.7572 radeon /radeon
776 2.4386 drm /drm
677 2.1275 ttm /ttm
565 1.7756 libc-2.28.so _IO_vfscanf
392 1.2319 libglamoregl.so /usr/lib/xorg/modules/libglamoregl.so
279 0.8768 libEGL_mesa.so.0.0.0 /usr/lib/libEGL_mesa.so.0.0.0
276 0.8674 radeon_drv.so /usr/lib/xorg/modules/drivers/radeon_drv.so
269 0.8454 libGLdispatch.so.0.0.0 /usr/lib/libGLdispatch.so.0.0.0
242 0.7605 libc-2.28.so exec_comm
212 0.6662 libglapi.so.0.0.0 /usr/lib/libglapi.so.0.0.0
178 0.5594 libpixman-1.so.0.34.0 /usr/lib/libpixman-1.so.0.34.0
160 0.5028 libEGL.so.1.1.0 /usr/lib/libEGL.so.1.1.0
95 0.2985 libfb.so /usr/lib/xorg/modules/libfb.so
86 0.2703 libdrm.so.2.4.0 /usr/lib/libdrm.so.2.4.0
Cette fois, la différence entre le pilote graphique et Xorg est encore plus grande, de préférence du pilote.
Cependant, il est intéressant de noter que l'entrée la plus dominante était le arena_get2.part.4
de la glibc. Qu'est-ce que cela pourrait être? Je n'ai pas pu trouver le résultat exact sur Google, mais j'ai trouvé trouver ce fichier source , ce qui suggère qu'il est très probablement lié à l'allocation de mémoire.
Pour réduire l'impact de celui-ci, les utilisateurs intéressés devraient probablement dans le cache malloc par thread l'optimisation faisant partie de la version 2.26 de la glibc. De nos jours, après tout ce qui s'est passé entre Spectre et Meltdown, l'optimisation est d'autant plus importante qu'il devient de plus en plus important de ne pas aller trop souvent dans l'espace du noyau.
Je présume, c’est paquet libc6 que Ubuntu Xenial a la version 2.23. Vous pourriez être tenté de mettre à jour ce paquet spécifique, mais soyez averti que cela pourrait casser quelque chose, car cette bibliothèque est au cœur même du système. La meilleure façon de l'obtenir serait de passer à 18.04 avec la version 2.27 .
Vous avez un processeur lent bas de gamme. Cela va montrer une charge élevée, même dans des conditions d'utilisation générale. Sites de référence le lister comme étant beaucoup plus lent que les processeurs bas de gamme traditionnels tels que Intel I5 5200u.