7 votes

Pourquoi le nombre de cœurs CPU disponibles change-t-il lorsque une application est fermée?

Pour trouver le nombre de cœurs disponibles dans Termux, vous exécutez:

grep Cpus_allowed /proc/self/status

Ce nombre de cœurs est limité de manière similaire à l'exécution de taskset sur GNU/Linux.

J'essaie de pouvoir prédire ce que cela va retourner.

Selon l'application CPU-Z, mon téléphone (Huawei Smart P) a 1 HiSilicon Kirin 659 avec 8 cœurs. Selon l'application CPU Info, 4 cœurs fonctionnent à la même vitesse (480-1709Mhz) et 4 cœurs fonctionnent à la même vitesse (1402-2362Mhz).

Après avoir démarré le téléphone et attendu 5 minutes pour m'assurer que toutes les tâches de démarrage ont été lancées / terminées, j'ai démarré Termux, me suis connecté via ssh et j'ai obtenu:

Cpus_allowed_list:       0-7

Ce à quoi je m'attends exactement.

Mais si j'appuie sur la touche d'accueil, j'obtiens:

Cpus_allowed_list:      2-3

J'ai pensé que cela pourrait être lié à la charge des cœurs, alors je suis retourné sur Termux, j'ai lancé 16 bzip2. Cela ne change pas le nombre de cœurs que j'obtiens immédiatement. Mais après 30 secondes, j'obtiens 4 cœurs:

Cpus_allowed_list:     0-3

Et plus tard, je suis ramené à 2 cœurs:

Cpus_allowed_list:      2-3

Ce comportement se produit via ssh que Termux soit au premier plan ou en arrière-plan.

L'effet de la touche d'accueil ne se produit que lors de l'exécution de Termux: si j'exécute CPU Info, puis j'appuie sur la touche d'accueil et ensuite démarre Termux, alors Termux a toujours 8 cœurs:

Cpus_allowed_list:       0-7

Seulement lorsque je change de Termux en utilisant la touche d'accueil, la touche de la liste des applications ou la touche de retour, le nombre de processeurs change.

La gestion logicielle big.LITTLE pourrait expliquer le passage de 8 à 4 cœurs si la limite n'était pas appliquée immédiatement après le démarrage, mais seulement activée par la suite. Comme la limite n'est pas activée 5 minutes après le démarrage, je pense qu'il est sûr de rejeter cela comme explication. Cela n'explique pas non plus la limitation à 2 cœurs parfois lors de l'exécution de 16 bzip2.

Qu'est-ce qui empêche le téléphone de me permettre d'utiliser 8 cœurs? Comment puis-je dire au téléphone de ne pas le faire? Qu'est-ce qui fait que la limite passe entre 2 et 4 cœurs à des intervalles apparemment aléatoires?

(En plus de cela, je m'attendais à ce que les cœurs fonctionnent à 100% de leur vitesse ce qui n'arrive pas non plus).

La limitation ne se produit pas si ce n'est pas exécuté via ssh ou si exécuté dans une session tmux où la session tmux est démarrée via le terminal sur le téléphone.

0 votes

Le CPU est un Octa core avec le concept BIG-little. Par conséquent, cette réponse s'applique également à votre CPU.

0 votes

@Robert SI c'était un processeur big.LITTLE, pourquoi j'obtiens 0-7 après le démarrage ? Cela reste ainsi si je ne presse pas sur accueil. top montre clairement 8 CPUS fonctionnant à 100%. De plus, cela n'expliquerait pas pourquoi je suis limité à seulement 2 cœurs parfois.

0 votes

Je présume que l'appareil démarre sans affectations spécifiques de CPU. Cela permet également de démarrer le plus rapidement possible. Ensuite (peut-être au démarrage d'un service spécial), il applique la configuration d'alimentation pour limiter la consommation d'énergie. Les nouveaux processus démarrent avec 2 cœurs et après 30 secondes d'utilisation intensive du CPU, les 4 cœurs rapides sont autorisés. Gardez à l'esprit que les smartphones sont optimisés pour la réactivité de l'interface utilisateur, pas pour le débit maximal du CPU.

3voto

Irfan Latif Points 16863

Qu'est-ce qui empêche le téléphone de me permettre d'utiliser 8 cœurs ?

Linux Control Groups (cgroups). Android les utilise pour contrôler combien de ressources un processus peut utiliser. En particulier, les processus des applications sont assignés à différents cgroups en fonction de leur cycle de vie, qui dépend généralement de l'interaction de l'application avec l'utilisateur.

Par exemple, une application actuellement utilisée en premier plan a besoin de plus de puissance de traitement que celle restant inactive en arrière-plan. Ainsi, Android crée de multiples sous-cgroups descendants pour différents états des processus d'application (et non d'application) :

~# grep . /dev/cpuset/*/cpus
/dev/cpuset/background/cpus:0-1
/dev/cpuset/foreground/cpus:0-6
/dev/cpuset/restricted/cpus:0-3
/dev/cpuset/top-app/cpus:0-7

cpuset est l'un des multiples types de cgroups qu'Android utilise à des fins différentes.

Comme vous pouvez le voir, les applications en arrière-plan sont autorisées à utiliser seulement 2 (sur 8) CPU, celles exécutant un service en premier plan peuvent utiliser 7 CPU, tandis que les applications principales peuvent utiliser tous les CPU. Le framework Android bascule continuellement le PID d'une application entre ces sous-cgroups lorsque l'application change de statut.

Notez que :

  • Différents fabricants peuvent configurer les cgroups différemment en fonction du nombre de cœurs CPU disponibles sur l'appareil.
  • Le réglage de l'affinité CPU d'une tâche en utilisant taskset est filtré pour les seuls CPU autorisés dans le cpuset de cette tâche.

Comment puis-je dire au téléphone de ne pas le faire ?

La meilleure façon serait de modifier le code et de reconstruire la ROM pour qu'elle n'utilise plus les cgroups (ou qu'elle les utilise comme vous le souhaitez). Ou simplement modifier les valeurs CPU dans les fichiers indiqués ci-dessus, en espérant qu'elles ne reviendront pas en arrière.

Mais pour un utilisateur normal, cela ferait plus de mal que de bien, consommant plus de ressources et affectant gravement les performances de l'appareil.


Liens Connexes :

-2voto

Sean Points 46

Résumé : plus vous utilisez de cœurs, plus vous consommez de batterie, donc le hotplugging du CPU éteint les autres cœurs, et les autres font le travail ce qui les amène à une utilisation CPU de 100%, ce qui donne également les meilleures performances et les plus équilibrées.

C'est le hotplug du CPU qui allume et éteint les cœurs selon les besoins.

Il fonctionne à 100% d'utilisation du CPU parce que c'est comme ça. Imaginez, il y a 4 voitures, et supposons que les conducteurs sont les cœurs. Vous avez quatre voies et 4 voitures bien sûr. Chacune prendra 100 pizzas. Vous pouvez laisser un cœur faire tout le travail c'est ce que fait le hotplugging. Sachant qu'une voiture avec 50 pizzas consomme beaucoup moins de carburant qu'une voiture avec 100 pizzas, vous pouvez maintenant voir comment nous pouvons avoir les mêmes performances et économiser du carburant : chargez deux voitures avec 50 pizzas et laissez-les accélérer le plus rapidement possible vers leur destination (gouverneur de performance). Ils y arriveront aussi rapidement qu'une voiture avec 100 pizzas (mêmes performances), mais consommeront moins de carburant (économie de batterie).

Si vous voulez que votre téléphone fonctionne sur 8 cœurs, alors vous devez installer un kernel personnalisé, utiliser un autre gouverneur de CPU, utiliser un hotplugging de CPU personnalisé, ou sans installer un kernel personnalisé utiliser un gouverneur interactif, puis ajuster ses paramètres. Vous pouvez rechercher sur XDA pour les ajustements avancés du gouverneur interactif.

1 votes

De plus, qu'est-ce qui, selon vous, donne la "meilleure performance équilibrée" en cas de charge élevée ? Certainement pas la désactivation des cœurs. Et 16 processus bzip2 ont certainement besoin de plus de 3 cœurs pour une "bonne performance". Pourriez-vous donc expliquer - et étayer votre affirmation?

0 votes

Utilisez un gouverneur interactif, puis ajustez ses paramètres.

0 votes

C'est la façon dont votre noyau active et désactive les cœurs si c'est nécessaire ou non au démarrage, tous les cœurs sont allumés car les démarrages Android sont parfois lents, donc les développeurs essaient d'allumer tous les cœurs pour le démarrer plus rapidement.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X