Apple explique pourquoi kernel_task monopolise votre processeur

Pierre Dandumont |

Si vous allez sur des forums, sur des réseaux sociaux ou si vous effectuez une recherche, vous verrez parfois que des utilisateurs paniquent parce qu'un processus nommé kernel_task monopolise leur processeur. Et dans une page de support mise à jour récemment, Apple explique pourquoi ce processus est important.

kernel_task

Dans un usage normal, kernel_task n'est pas la cause d'une chauffe extrême de votre Mac, comme Apple l'explique, mais bien une conséquence. Si votre Mac semble « ramer » ou s'il semble trop chaud, le fait que kernel_task utilise une grande partie du temps du CPU est normal et ce n'est pas la cause de votre problème.

Prenons le cas des puces Intel, qui souffrent un peu plus du problème que les Mac Apple Silicon. Chez Intel, donc, un CPU propose d'abord plusieurs fréquences : celle de base (par exemple 3 GHz sur un Core i5 8500B vu dans un Mac mini 2018). Intel définit ensuite des fréquences dites « Turbo », qui varient selon les puces. Dans le cas du CPU en question, elle varie de 3 900 MHz (cinq ou six cœurs utilisés) à 4,1 GHz (sur un seul cœur) en passant par 4 GHz (entre les deux). La fréquence Turbo est contrôlée par le CPU, qui va prendre en compte le TDP de base (65 W) et le TDP « Turbo » (plus élevé et valable de quelques secondes à quelques minutes). Dans les faits, le processeur, couplé à l'OS, va tenter d'obtenir la fréquence la plus élevée sans dépasser le TDP, équivalent à la consommation.

Le processus kernel_task est là pour aider le CPU, dans des cas spécifiques : il va charger le CPU pour faire baisser la température notamment quand la limite haute (vers 100 °C, en fonction des puces) est atteinte à la fréquence de base. Il ne devrait pas s'activer quand vous effectuez une tâche qui charge un cœur à sa fréquence maximale, par exemple : le mode Turbo est le comportement attendu. De même, il ne va probablement pas s'activer si vous effectuez une longue tâche sans que la température s'approche de la limite. Mais si vous avez un Mac mal ventilé ou sans ventilation active (comme un MacBook), il pourrait s'activer de temps en temps.

Si l'intérieur de votre Mac ressemble à ceci, il y a un souci (image LeiHao's Blog)

Vous vous posez probablement une question : « Comment un processus peut-il faire diminuer la température ? ». La réponse est simple : avec une instruction dédiée. Les jeux d'instructions intègrent généralement en effet une instruction dite « NOP » (pour No OPeration) qui n'effectue rien. Et c'est précisément l'intérêt de kernel_task : un processus qui va utiliser une partie du temps du processeur (plus ou moins élevée) sans rien faire. Dans le cas d'une surchauffe, l'effet est immédiat : si le processeur ne fait rien pendant 50 % du temps, sa température va mécaniquement diminuer. Et comme Apple l'explique, l'utilisation de kernel_task est liée à la température : dès qu'elle diminue, l'activité de kernel_task décroît.

Que faire si kernel_task monopolise le CPU ?

La première chose à faire, si kernel_task monopolise le CPU, est de vérifier qu'une autre tâche ne monopolise pas le CPU. Ce n'est pas très intuitif ni très visible, mais la cause principale de son activation est une application qui fait chauffer le CPU. Le second problème est matériel : si aucune application ne semble poser de souci particulier, il se peut que votre Mac soit mal refroidi. Il peut s'agir d'un dissipateur d'un ventilateur encrassé, d'un ventilateur qui ne fonctionne plus ou — c'est plus étonnant — la chauffe d'un composant qui va influer sur la température du CPU. Le cas de certains MacBook Pro est le plus évident : la charge sur les ports de gauche de certains Mac fait chauffer la puce Thunderbolt, qui active le processus kernel_task.

Message de service : chargez votre MacBook Pro à droite

Message de service : chargez votre MacBook Pro à droite

Dans tous les cas, il faut bien prendre en compte un point : le Mac surchauffe pour une raison ou une autre, et ce n'est pas nécessairement le CPU même si c'est probablement le principal suspect. Les puces d'Apple souffrent moins du problème que celles d'Intel pour plusieurs raisons. La première est évidente, elles chauffent moins. La seconde vient du fait qu'il n'y a pas réellement de mode Turbo1 ni de TDP. La seule limite est en pratique la température, avec une limite assez haute.

Les bugs ne sont pas à exclure

Il y a un dernier point à ne pas oublier : les bugs existent. Il se peut que le processus s'active sans raison particulières ou suite à un bug. Mais avant de pousser des cris d'orfraie sur la finition des OS d'Apple, il vaut mieux vérifier si une application n'est pas la cause ou s'il n'y a pas un problème matériel. Si le problème persiste, la solution la plus évidente est de réinitialiser le SMC, le composant qui gère les capteurs de température, et donc indirectement l'activation du processus. Apple explique les trois méthodes sur son site, qui dépendent du type de Mac. Elles diffèrent si vous avez un Mac avec une puce Apple Silicon, un Mac avec une puce T2 ou un Mac sans puce T2.


  1. Au sens Intel du terme, avec une fréquence de base et des fréquences plus élevées.  ↩︎

Source
Image d'ouverture : Creative Electron
avatar Yohmi | 

Merci pour l'info ! J'imaginais pas du tout ce type de fonctionnement, c'est très instructif ☺️

avatar tofman | 

Enfin une explication, j’ai failli balancer mon MacPro poubelle par la fenêtre je ne sais combien de fois à cause de ce truc qui bloquait tout alors que j’avais des centaines d’exports sous Lightroom à faire.
Et d’ailleurs depuis un an, plus jamais, je n’ai jamais compris

avatar zcomzorro | 

Un article de saison!

avatar radeon | 

Très intéressant mais du coup ça soulève pour moi une autre question, j’ai pu constater de forts pics réseau rattachés à ce processus, quel en est la finalité ?

avatar xDave | 

@radeon

Je crois que c’est associé à des logs qu’il essaye d’envoyer.
En tout cas ça bloque le réseau aussi.
Ethernet /Wifi voire AirDrop bloqués ou extrêmement ralenti.
Dans mon cas, si j’ai eu le malheur de lancer une application juste avant. C’est la panique totale.
Photoshop ne reconnaît même plus ma carte graphique et autre messages cryptiques, l’authentification deconne à plein tube.
Une horreur.

avatar radeon | 

@xDave

Ok c’est plutôt logique maintenant que tu le dis, heureusement pour moi j’ai pas eu de tel cataclysme avec ce processus, ça fait pas semblant sur ton ordi c’est quel modèle ?

avatar xDave | 

@radeon

MacBook Pro 15 2017 avec TouchBar.
Pire qu’un Mac II pour bosser 😅
Quand ça commence, je tape plus vite que le processeur, et il intervertit la frappe.
Un truc de fou.
J’ai pu tenir quelques jours en débranchant moniteur externe etc mais c’était pas la panacée .

avatar radeon | 

@xDave

Ouille et t’as essayé les supports ventilés pour aider le refroidissement ?

avatar oomu | 

@xDave
"Ethernet /Wifi voire AirDrop bloqués ou extrêmement ralenti. "

la cause n'est pas kernel_task, son activité virtuelle ne serait qu'un symptôme de plus du problème sous-jacent de soucis réseau.

"
"Dans mon cas, si j’ai eu le malheur de lancer une application juste avant. C’est la panique totale.
Photoshop ne reconnaît même plus ma carte graphique et autre messages cryptiques, l’authentification deconne à plein tube."

idem là aussi
kernel_task ne peut pas être la Cause de votre problème de photoshop et "messages crypytiques" (par ailleurs: copiez nous vos messages cryptiques, ils peuvent ne pas être si cryptique).

" l’authentification deconne à plein tube."

ici, non seulement votre description est trop vague (authentification de quoi ? un site web ? session macos ? adobe creative cloud ?)
mais encore une fois, ça ne peut pas être "kernel_task" la raison du problème.

là aussi, vous avez un autre problème sous-jacent.

avatar nononap | 

@radeon

C'est parce que l'article est très (trop ?) réducteur (et la plupart des articles à ce sujet). kernel_task représente le kernel dans son ensemble (quand le kernel se lance, task_init() créer une task Mach qui le représente). Il apparait d'ailleurs dans les spindump pour montrer les backtraces qui sont dans le kernel.

Du coup, si vous avez le kernel (ou une extension kernel) qui fait des accès réseau, du genre NFS (qui est implémenté dans le kernel via une extension kernel si je me souviens bien), Activity Monitor associera cette activité à kernel_task.

avatar radeon | 

@nononap

Je vais devoir googler certains termes mais c’est très intéressant, merci 🙏
@Macge : un petit approfondissement sur le sujet ça me tenterait bien :)

avatar nononap | 

Bonne chance, la plupart des articles vont dans le même sens (kernel_task = tache chiante qui consomme du CPU pour faire baisser la température du CPU…).

Le mieux reste de lire le code source du kernel (projet XNU, open source), ou encore de lire des livres assez techniques (je pense au bon vieux Mac OS X Internal: A Systems Approach, de Amit Singh - il est un peu obsolète, mais beaucoup de choses dont il parle n'ont pas changé, ou encore les livres de Jonathan Levin, du genre Mac OS X and iOS Internals - To the Apple's Core, qui commence à dater aussi, mais est toujours valide sur pas mal de sujets).

avatar radeon | 

@nononap

Super, merci pour les refs :)

avatar Yohmi | 

@nononap
"Le mieux reste de lire le code source du kernel"
C'est clair ! Et ce soir on se fait une fondue assembleur, où celui qui perd son bout de pain doit réciter Hello World en assembleur x86, et attention, sans cracher son bout de pain, l'éclate totale 😀😀😀

avatar nononap | 

@Yohmi

Tout peut pas être du Swift-lol ;p

avatar oomu | 

@Yohmi

c'est bien sur technique

mais le code source de MacOs est essentiellement en C et c'est donc relativement facile à lire pour comprendre son fonctionnement interne.

Nombre d'articles de site techniques qui décortiquent macos sont simplement des interprétations du code.

Et je confirme:Mac OS X Internal: A Systems Approach, de Amit Singh est un chouette livre pour comprendre le fonctionnement internet de MacOs

dommage qu'il ne soit pas remis à jour.

avatar xDave | 

@nononap

Oui tout à fait.
Et difficile d’identifier le coupable.

avatar xDave | 

Hahaha
Ca sent le vécu.
Kernel task qui bloque tout.
Mon MBP un ventilo mort. Kernel toutes les 30 minutes.
Inutilisable. Et évidemment pas remplaçable.

avatar ⚜Dan | 

@xDave

Change le ventillo lol

avatar xDave | 

@⚜Dan

C’est tout collé soudé. Impossible.
Faut changer tout le top case. Plus de 1000€ de reparation.

Sinon je l’aurais fait. Ça m’était déjà arrivé sur un PowerBook.

avatar ⚜Dan | 

@xDave

Je ne connais pas ton model mais normalement tout les ventilo peuvent être interchanger sur les mbp. C’est pas une pièce soudé!

avatar Lightman | 

@xDave

Sur mon MBP les ventilos tournent presque 24 h / 24 h. Au bout d'un certain temps les paliers prennent du jeu et ils vibrent. Je les ai déjà changés trois fois, ce n'est pas trop cher en occasion.
J'ai la génération la plus intéressante pour le bricolage : j'y ai déjà changé le top case (chute d'une voiture en roulant), changé une capa sur la carte mère, monté un 2e disque dur interne, etc.
Le meilleur pour la fin : MacBook Pro 6,2 (mi-2010). Increvable 😄

avatar PtitXav | 

Merci pour cette explication. Conséquence et non cause.

avatar Captain Bumper | 

kernel_task ne sert qu’à (ou essentiellement à) ça??! 😯😳
Moi qui pensais que c’était le noyau de macOS et donc que ça gérait tout ce qu’un noyau gérait : accès mémoire, gestion du multitâche etc. et donc je trouvais normal qu’il travaille plus quand une autre application travaille bcp demandant des accès réguliers au système.

avatar nononap | 

@Captain Bumper

Non non, l'article (comme la plupart des articles sur le sujet) est très / trop réducteur (voir mon autre commentaire). kernel_task représente bel et bien le kernel dans son ensemble.

Il est créé par la fonction task_init(void) -> task_create_internal(...) quand le kernel se lance, et l'espace mémoire du kernel (kernel_map) y est associé.

C'est juste que cette fonction de baisse de température fait partie du job du kernel (et donc associé à la kernel_task).

avatar Captain Bumper | 

@nononap : ah je me disais aussi….. ton explication me paraît bien plus convaincante (et logique, surtout que le pid de kernel_task est toujours 1 (ou 0), s’agissant du processus initial lancé en premier, on se doute que cela doit être la base du système). Dommage que le Moniteur d’activité ne puisse pas montrer les sous-taches au sein d’un même processus cela permettrait d’en apprendre plus (et sûrement de résoudre un paquet de blocages en voyant quelle tache fait foirer une application ou le kernel).

avatar nononap | 

@Captain Bumper

> surtout que le pid de kernel_task est toujours 1 (ou 0)

Pour le kernel, le PID est assigné à 0 (le "process" BSD représentant le kernel est "créé" un peu plus tard, dans bsd_init(void) - via une structure hard codée proc0 / kernproc - je le précise, parce que c'est de là que vient le 0 dans le nom de cette structure).

Le PID 1 c'est launchd (il fût un temps il y avait un launchd système, et un par utilisateur, mais maintenant c'est tout géré par le même launchd, entre autre).

> Dommage que le Moniteur d’activité ne puisse pas montrer les sous-taches au sein d’un même processus cela permettrait d’en apprendre plus (et sûrement de résoudre un paquet de blocages en voyant quelle tache fait foirer une application ou le kernel).

Si par sous-tâche vous entendez les threads, vous pouvez avec un sample ou un spindump (ça n'est pas possible de sampler le kernel, mais le spindump si, même s'il ne montre pas que lui).

Spindump comme Sample prennent un "snapshot" tous les x millisecondes du processus, pendant un temps y, et vous montre l'agrégation de ces snapshot qui ressemble un peu à "j'ai vu ce process être en train d'exécuter ce code-là dans ce thread là z fois en tout"). Très utile pour comprendre des problèmes de performances, de blockage, ou d'inter-blockage.

avatar Captain Bumper | 

@nononap : je connais le spindump mais c’est overkill et souvent illisible pour l’amateur éclairé. Je pensais plus à un petit triangle sur le côté permettant de dérouler une liste de sous taches (de thread) explicites permettant par la même occasion de connaître l’occupation CPU/RAM/GPU et accès DD de chacune des sous taches. Mais j’imagine que cela nécessite une programmation spécifique des applications (pour les « découper » en thread bien explicite) et du système 🤷🏼‍♂️

avatar nononap | 

@Captain Bumper

> je connais le spindump mais c’est overkill et souvent illisible pour l’amateur éclairé.

C'est pas faux.

> Je pensais plus à un petit triangle sur le côté

En vrai c'est possible en théorie, en tout cas pour le CPU (les API nous donnent la consommation par thread, c'est ps / top / Activity Monitor qui additionnent ensuite).

Pour la RAM, c'est peut-être possible avec le ledger de macOS, mais je n’en sais rien. Le man de la commande `footprint(1)` n'en dis rien en tout cas.

La vraie difficulté c'est que beaucoup de threads peuvent être continuellement créés / supprimés (surtout avec la lib dispatch), pour des tâches qui n'ont rien à voir entre elles (recyclage de thread), alors pas évident à présenter.

avatar oomu | 

@Captain Bumper
ce n'est pas spindump ni l'analyse des threads

mais en ligne de commande, vous avez l'utilitaire
fs_usage
qu peut vous être utile

fs_usage vous montrera TOUS les appels système pour les entrées/sorties (les fichiers sur stockage mais aussi tous ce qui est vu comme des fichiers )

ça permet de remarquer si un process ne cesse de harceler le stockage et sur quoi.

avatar Angusalex | 

Super article merci

avatar bent.o | 

Excellent article 👏

avatar Levidi | 

😃💡👌🏻

avatar LogBoy | 

He ben j'en apprends une bonne, merci beaucoup.

avatar Jcleon95 | 

Dans mon cas il y a 1 an et demi c’était une horreur avec mon Intel. C’est pour ça que je suis passé sur le M1 car la cause était inconnu (problème matériel, système et cela mal grès les réinstallation). Vu qu’Apple m’a repris mon 21’ 600€ j’ai pas hésité vu qu’il avais 8ans. Trouve t’on un PC qui est repris par le fabriquant ce prix?

avatar xDave | 

@Jcleon95

Tu as du bol.
Mon MBP repris 0 euro

avatar Jcleon95 | 

@xDave

J’avais remis le disque d’origine à la place du SSD et réinstallé vierge. Dans cette configuration il tournait bien. Il correspondait bon configuré au demande d’Apple et donc rien ne pouvait être constaté d’un premier abord.

avatar Jcleon95 | 

@xDave

En même temps à l’époque en plus je leur ai pris le 16g, Care mais que 512 Go. Grosse erreur. Je trouvais que ça irai vu que mon 1To n’avait jamais été rempli et que le SSD était un 500. Maintenant que j’utilise FinalCut je pleur. Je laisse juste les fichiers de travail sur l’interne et ensuite je déplace sur les SSD externe.

avatar manuinbangkok | 

Excellent article merci !

avatar irep | 

Quand j’allume ou redémarre mon iMac Intel, il faut 10 vraies minutes avant de pouvoir vraiment interagir avec lui. Ce n’est pas la phase initiale avec la barre de progression qui est lente, c’est à partir de l’affichage du bureau. La souris est mobile bien avant ça, les fenêtres du Finder se rouvrent aussi, je peux les déplacer mais pas les refermer et si je double-clique sur un fichier, je dois attendre le démarrage complet pour qu’il s’ouvre.
Après tout ça, le Mac va très bien.
J’ai fait un clean install, mais dès l’installation des Adobe et Microsoft officiels le Mac a commencé ce comportement. J’installe et dépanne des Macs depuis des années pour des clients et je n’ai jamais vu ça.

avatar raoolito | 

@irep

imac ssd ?

avatar irep | 

@raoolito

iMac Fusion Drive

avatar raoolito | 

@irep

je n’ai évidemment pas votre niveau tech, mais j’irai chercher de ce côté perso. si le micro-ssd qui sert de tampon est mort, genre 80% des cellules sont hs, alors le fusion drive a des performances réduites gravement

avatar irep | 

@raoolito

Merci. Mais le Mac n’est lent qu’au démarrage. Quand on a enfin la main, tout va bien. J’ai aussi utilisé un programme qui désactive des démons de démarrage (daemons), mais je ne suis pas parvenu à fixer le problème.

avatar raoolito | 

@irep

et avez-vous tenté bootcamp? avec windows ou linux… de cette manière vous sauriez si c’est macos ou autre chose? (clef usb de boot type ubuntu aussi)

avatar irep | 

@raoolito

Non, je n’ai jamais utilisé BootCamp. J’essayerais bien.
Au clean install j’aurais dû créer un compte non administrateur pour y ajouter les applications pour ce user seulement.

avatar raoolito | 

@irep

ca ‘e semblerait enorme que ce soit un truc du genre…
ca sent le soucis hardware, sachant qu’une fois loades en ram les os sont assez rapide…

avatar oomu | 

@irep

Adobe et Microsoft installent des logiciels qui préchargent leurs gigantesques logiciels ?

Regardez ce qui est démarré automatiquement avec votre ouverture de session.

avatar oomu | 

@irep

mais là aussi, c'est hors sujet: "kernel_task" y est pour rien.

avatar Lancelot68 | 

@Irep.
Je travaille hélas sur Windows pour le boulot depuis 30 ans et je peux vous dire que ce phénomène et très courant. CPU à 100% seulement en écrivant un mail ou Excel freezé pour des dizaines de minutes parce que la connexion réseau n’est pas au top pendant 10 sec….
Depuis 2 mois passé à un environnement sécurisé Microsoft et tout peu foire.
Le problème est peut être chez MS???? :)

Pages

CONNEXION UTILISATEUR