web-dev-qa-db-fra.com

Donner un sens au Temps dans dmesg

Je sais que le temps dans dmesg est le temps écoulé depuis le démarrage. Mais ma question spécifique est que ce temps est calculé au début ou à la fin du processus mentionné dans la ligne?

Pourquoi c'est important?
prenons cet exemple:

[    4.352025] floppy0: no floppy controllers found
[    5.718270] random: nonblocking pool is initialized
[   94.134265] Adding 2094076k swap on /dev/sda5.  Priority:-1 extents:1 across:2094076k FS**
[   96.988453] init: bootchart main process (274) terminated with status 127

Si le temps est calculé après la fin du processus, le processus de la 3ème ligne doit être considéré comme responsable du démarrage lent.
Mais si le temps est calculé à partir du début du processus, la 2e ligne en sera responsable.

Mais cela devient plus compliqué lorsque nous vérifions dmesg longtemps après le démarrage.
Prenons ceci par exemple:

[28047.749604] wlp3s0: associated
[28941.112855] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=757985 end=757986)
[31407.938694] cfg80211: World regulatory domain updated:
[31407.938699] cfg80211:  DFS Master region: unset

Cet écart de 2466 ne devrait pas avoir de signification utile.

Je vois beaucoup de fois qu'il y a confusion à propos de la ligne dans dmesg qui devrait être tenue responsable du démarrage lent.

Comment pouvons-nous donner un sens au temps dans dmesg?

3
Mostafa Ahangarha

dmesg n'est pas un test fiable de la durée d'un processus de démarrage ou de l'emplacement des goulots d'étranglement. Selon Wikipedia page:

Lors du démarrage initial, un système informatique charge son noyau en mémoire. À ce stade, les pilotes de périphérique présents dans le noyau sont configurés pour piloter le matériel approprié. Ces pilotes, ainsi que d’autres éléments du noyau, peuvent produire une sortie ("messages") indiquant à la fois la présence de modules et les valeurs des paramètres adoptés.

En d'autres termes, dmesg elle-même ne collecte que des informations. Ce sont les pilotes et autres processus système qui génèrent ces messages, et ils peuvent les émettre à tout moment. Entre ces messages, d'autres processus ont peut-être été créés, ce qui ne permet donc pas de savoir depuis combien de temps le système démarre.

dmesg collecte également les messages en continu à partir de la mémoire tampon en anneau, de sorte que votre délai de 2466 n'indique pas un processus suspendu, mais simplement qu'un événement se produit 2466 plus tard et que le processus qui était actif à ce moment-là ne fait que générer un message du noyau.

Ce que vous voulez, cependant, c'est tableau de démarrage , qui est utilisé spécifiquement pour rechercher des goulots d'étranglement au cours du processus de démarrage. Je ne l'ai vu que référencé sur plusieurs forums et sur ce site, mais je ne l'ai jamais utilisé moi-même. Je ne peux donc pas vous donner plus d'informations que cela.

4

La commande dmesg lit le tampon printk du noyau en utilisant le mode d'accès à l'espace utilisateur via /dev/kmsg. Chaque entrée a un horodatage monotone en microsecondes défini lors de la création de l'entrée de journal.

La question ne peut donc pas être de savoir quel timestamp dmesg (ou le noyau) se connectera mais doit indiquer quand le noyau créera l'entrée de journal pour une action spécifique qu'il effectue.

Comme je suppose, cela peut différer d'une action à l'autre. Lorsqu'un événement survient dans le noyau, c’est-à-dire branchez un périphérique USB, le noyau le notera dès qu’il aura des informations utilisables. Lorsque le noyau effectue une tâche planifiée, il est logique de consigner les résultats lorsque le travail est terminé. S'il s'agit d'un travail complexe, il génère peut-être des entrées de journal pendant son exécution, mais comme je suppose généralement après qu'un événement intéressant s'est produit ou qu'il reste un peu de temps.

Comment vous pouvez accéder au tampon printk du noyau est expliqué ici .

Donc, si vous voulez spécialement savoir si une certaine entrée est enregistrée au début ou à la fin d'une action, vous devez consulter le code de noyau ou de module lorsque le programme appelle la fonction de journalisation.

2
cmks