Pourquoi l'utilisation du processeur kworker est-elle si élevée ?

Plutôt, je pense que cette utilisation de CPU n'est pas normale et est liée au bug kworker bien connu : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793

La solution pour moi et pour beaucoup d'autres était, tout d'abord, de trouver le "gpe" qui cause des problèmes avec quelque chose comme :

grep . -r /sys/firmware/acpi/interrupts/

et vérifiez s'il y a une valeur élevée (pour moi, c'était gpe13 - avec une valeur comme 200K - donc, vous devez la changer en conséquence, si elle est différente). Ensuite :

~ cp /sys/firmware/acpi/interrupts/gpe13 /chemin_de_sauvegarde
~ crontab -e

Ajoutez cette ligne, pour qu'elle soit exécutée à chaque démarrage/redémarrage :

@reboot echo "disable" > /sys/firmware/acpi/interrupts/gpe13

Enregistrez/sortez. Ensuite, pour que ça fonctionne également après la reprise depuis la suspension :

~ touch /etc/pm/sleep.d/30_disable_gpe13
~ chmod +x /etc/pm/sleep.d/30_disable_gpe13
~ vim /etc/pm/sleep.d/30_disable_gpe13

Ajoutez ceci :

#!/bin/bash
case "$1" in
    thaw|resume)
        echo disable > /sys/firmware/acpi/interrupts/gpe13 2>/dev/null
        ;;
    *)
        ;;
esac
exit $?

Enregistrez/sortez, c'est tout.

Testé et fonctionne sur :

Ubuntu 12.10 sur Samsung Chronos 7 series - Modèle NP700Z7C --
Ubuntu 16.04.2 sur Clevo - Modèle P650RS --

L'utilisation du processeur semble être normale, il n'y a qu'un seul CPU (CPU1) qui a une utilisation élevée. En tout, il y a un total de 3 processus qui sont dans l'état d'exécution, deux d'entre eux étant kworker et gnome-system-mo (les 2 premiers processus dans la capture d'écran de la commande top que vous avez ajoutée).

"kworker" est un processus de substitution pour les threads de travail du noyau, qui effectuent la plupart du traitement réel pour le noyau, surtout dans les cas où il y a des interruptions, des timers, des E/S, etc. Ils correspondent généralement à la grande majorité de tout le temps système attribué aux processus en cours d'exécution. Ce n'est pas quelque chose qui peut être enlevé en toute sécurité du système de quelque manière que ce soit, et n'a absolument aucun lien avec nepomuk ou KDE (sauf dans le fait que ces programmes peuvent appeler des systèmes, ce qui peut nécessiter que le noyau fasse quelque chose)

Pour plus d'informations sur kworker, veuillez consulter le lien suivant : Qu'est-ce que KWorker et quelle est son importance

J'ai installé Linux Mint 17 hier et j'ai remarqué ce soir que kworker consommait 100% d'un des 4 processeurs. J'ai exécuté la vérification ci-dessus, mais je n'ai rien trouvé d'autre que 0 pour les interruptions.

En examinant les services que j'ai normalement en cours d'exécution, j'ai remarqué que l'arrêt du serveur nfs faisait chuter le thread kworker à zéro. Un redémarrage du serveur nfs n'a pas résolu le problème.

J'ai trouvé ce rapport de bug (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322407), qui indique qu'un problème similaire avec le serveur nfs a été corrigé dans le noyau 3.13.0-32.57. La dernière mise à jour de Mint 17 semble exécuter le noyau 3.13.0-24-generic, donc je n'ai pas la correction dans le noyau que j'utilise. Je ne sais pas si cela aidera quelqu'un d'autre mais je suis systématiquement allé sur chaque machine cliente nfs et j'ai fait un 'umount -a -t nfs' et j'ai attendu pour voir si cela avait un effet. J'ai trouvé le client qui semblait être à l'origine du problème car le kworker est tombé à zéro après que je l'ai démonté. J'ai remonté les partages nfs sur le client 'mount -a -t nfs' et le problème n'est pas revenu.