Pourquoi le CPU a passé du temps sur IO (wa)?

Je sais wa(en top) mesure le temps CPU en attente d'E / S. De nombreux articles le disent.

Mais je suis confus sur la base de 2 points de connaissance:

si un processus utilise un appel système pour lire le disque, le processus est bloqué.
Si un processus est bloqué, il ne peut pas être planifié en cours d'exécution sur le processeur.

Droite?

Il semble qu'il n'y ait pas de temps pour que le CPU attende les E / S ... Que se passe-t-il?

Si je recommande des livres ou des articles pour ma lecture, tant mieux.

linux central-processing-unit io linux-kernel

— HUA Di
source

Je suis intervenu et j'ai écrit une bonne réponse. Désolé je n'étais pas là quand tu avais besoin de moi ;-)

— Alec Teal

Réponses:

L'état inactif du processeur est divisé en deux sous-états différents: iowaitet idle.

Si le CPU est inactif, le noyau détermine alors s'il y a au moins une E / S en cours vers un disque local ou un disque monté à distance (NFS) qui a été lancé à partir de ce CPU. S'il y en a, alors le CPU est en état iowait. Si aucune E / S en cours n'a été lancée à partir de cette CPU, la CPU est en idleétat.

Donc, iowaitest le pourcentage de temps pendant lequel le CPU est inactif ET il y a au moins une E / S en cours initiée à partir de ce CPU.

Le iowaitcompteur indique que le système peut gérer plus de travail de calcul. Ce iowaitn'est pas parce qu'un processeur est en état qu'il ne peut pas exécuter d'autres threads ou processus sur ce processeur.

Donc, iowaitc'est simplement une forme de temps mort.

— le chaos
source

C'est en fait faux. Aussi NFS - le CPU n'a même pas un concept de cela. C'est essentiellement le temps que le processeur a passé à ne pas pouvoir faire autre chose car il traite des choses d'E / S de bas niveau - dans le sens d'accéder à quelque chose qui lui est connecté, PAS de traiter les E / S qui lisent généralement des fichiers et ainsi de suite. Par exemple, sur le Raspberry Pi, il n'y a pas de contrôleur DMA, donc le processeur ne peut pas "hey Motherboard me lire autant d'octets à partir de la carte et les mettre dans le ram à partir d'ici", il doit le faire manuellement->

— Alec Teal

il passe donc BEAUCOUP de temps à attendre en permanence io comme pour la lecture d'une carte. Vous donnez l'impression qu'un échec de cache peut être mesuré par cette «io attente» (qui bien sûr n'est pas comptée), l' attente d'E / S est définie comme suit: Le temps que le noyau a passé dans une routine d'E / S de périphérique de bas niveau - par exemple le RPi, il doit littéralement faire la procédure de lecture de la carte et le CPU (étant un chump sans DMA) doit attendre les données sur le bus IO. Avec un contrôleur DMA, il parle au contrôleur et dit "dites-moi quand vous avez terminé" - le laissant faire d'autres choses pendant que le contrôleur DMA fait des E

— Alec Teal

Utilisez dstat pour voir IOwaiting BTW, également iowait et le temps passé à faire des trucs de noyau ne peut pas vraiment être mesuré par processus. Comme par exemple, il existe deux processus "d'écriture" dans des "fichiers", le premier se termine rapidement, le FS a choisi de mettre en cache les écritures pour une raison quelconque, le second provoque le vidage du cache, il n'est pas juste de compter le temps de retour beaucoup plus long de l'écriture au processus qui a provoqué l'écriture. Même chose avec l'attente des E / S, c'est pourquoi elles ne sont pas mesurées par processus.

— Alec Teal

@AlecTeal: Non, c'est correct et vos commentaires sont faux. iowait compte le temps bloqué sur les E / S, pas l' entretien des E / S. Si vous ne voulez pas confirmer cela en lisant la source du noyau, essayez une expérience: montez un système de fichiers réseau, commencez à lire un fichier, puis pare-feu sur la machine distante. Le temps d'attente sera toujours élevé même si le processeur est complètement inactif.

— David

J'ai fait un test sur cette réponse. dd if=/dev/sda of=/dev/nullfaire un high wa. Exécutez ensuite un code while-true, wais au lieu de us. Merci le chaos.

— HUA Di

-2

Je ne suis pas sûr à 100% de comprendre la question, mais il y a quelques idées.

Il y a une autre question ici qui a posé cette question et a de bonnes réponses: Quelqu'un peut-il expliquer précisément ce qu'est l'IOWait?

Il y a un bon article ici: http://veithen.github.io/2013/11/18/iowait-linux.html

— Mike Fiedler
source

Mike, il est préférable que les réponses incluent du contenu, pas seulement des liens vers du contenu. En fournissant du contenu ici, vous vous assurez que votre réponse a toujours de la valeur lorsque ces liens disparaissent.

— EEAA

@EEAA alors la réponse doit être modifiée, pas triplement votée? Ou il peut être déplacé dans un commentaire. Il contient toujours des informations utiles. Les downvotes signifient en quelque sorte que l'info est inutile, aussi en la rendant presque invisible? Je ne dis pas que vous avez voté contre, je me demande simplement quelle est l'approche des gens ici.

— Roland Pihlakas

@RolandPihlakas C'est une question de motivation. Downvote + commentaire dans cette situation motive l'utilisateur à corriger sa réponse. Je retirerai volontiers mon dv une fois la réponse corrigée. Leur modification est contre-productive, car elle permet un mauvais comportement. Nous avons eu plusieurs utilisateurs à travers les années qui ont seulement jamais posté de réponses lien uniquement, malgré être demandé de ne pas le faire. Si les utilisateurs ne peuvent pas prendre la peine de faire un peu d'effort dans leurs réponses, je ne vais pas les aider en corrigeant leur travail.

— EEAA

@EEAA Merci pour la réponse détaillée. Votre approche est compréhensible et à travers vos commentaires, vous fournissez également le coup de pouce de la motivation à l'auteur de la réponse. En revanche, je crains que les downvotes silencieux ne fournissent généralement aucune motivation pratique car ils sont obscurs. Mais j'étais un peu imprécis - je me demandais surtout pourquoi la réponse avait-elle été tellement rejetée qu'elle était grisée? Votre commentaire avec un ou deux downvotes aurait dû suffire?

— Roland Pihlakas du

@RolandPihlakas Les gens pensaient que la réponse n'était pas utile, alors ils ont voté contre. Ils ont voté parce que c'est mardi. Ils ont voté parce qu'il neige à Minneapolis aujourd'hui (vraiment, ça l'est, et cela ne devrait pas être aussi tard au printemps). Qui sait.

— EEAA