Utilisation de perf pour savoir quand et pourquoi le processus entre en veille ininterruptible

Question

Je joue avec perf pour savoir comment on peut comprendre pourquoi le processus passe en état "D" (sleep ininterruptible).

J'utilise la commande perf:

perf record -g -p 4710 -e sched:sched_stat_iowait,sched:sched_stat_blocked sleep 60 

où 4710 est pid de mon processus appelé meetmaker.

Alors je regarde la sortie perf script qui est

meetmaker-3.0.0 4710 [008] 19187729.668851: sched:sched_stat_iowait: comm=jbd2/dm-2-8 pid=697 delay=120641 [ns] 
     ffffffff810a08a0 enqueue_sleeper ([kernel.kallsyms]) 
     ffffffff810a08a0 enqueue_sleeper ([kernel.kallsyms]) 
     ffffffff810a756a enqueue_entity ([kernel.kallsyms]) 
     ffffffff810a7e83 enqueue_task_fair ([kernel.kallsyms]) 
     ffffffff810967b1 ttwu_activate ([kernel.kallsyms]) 
     ffffffff81096983 ttwu_do_activate ([kernel.kallsyms]) 
     ffffffff8109819a ttwu_queue ([kernel.kallsyms]) 
     ffffffff810983fe try_to_wake_up ([kernel.kallsyms]) 
     ffffffff810ada66 autoremove_wake_function ([kernel.kallsyms]) 
     ffffffff810ad8fa __wake_up_common ([kernel.kallsyms]) 
     ffffffff810addb8 __wake_up ([kernel.kallsyms]) 
     ffffffff810ade11 __wake_up_bit ([kernel.kallsyms]) 
     ffffffff81260fcb ext4_finish_bio ([kernel.kallsyms]) 
     ffffffff812617df ext4_end_bio ([kernel.kallsyms]) 
     ffffffff8131b433 blk_update_request ([kernel.kallsyms]) 
     ffffffff8131b5b7 blk_update_bidi_request ([kernel.kallsyms]) 
     ffffffff8131c9af blk_end_bidi_request ([kernel.kallsyms]) 
     ffffffff8148f1f0 scsi_io_completion ([kernel.kallsyms]) 
     ffffffff813263bb blk_done_softirq ([kernel.kallsyms]) 
     ffffffff8106af9c __do_softirq ([kernel.kallsyms]) 
     ffffffff8106b1e5 irq_exit ([kernel.kallsyms]) 
     ffffffff816399fa do_IRQ ([kernel.kallsyms]) 
     ffffffff8163796d ret_from_intr ([kernel.kallsyms]) 
        487f77 [unknown] ([unknown]) 
        487f77 meetmaker__user_counters_get (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        505cff gpbrpc_exec (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        4eb45c ipc_game_loop (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        4ed48a game (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        48ebe3 service_late_init (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        47371a main (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
      7fd3cc391c36 __libc_start_main (/lib64/libc-2.11.3.so) 

meetmaker-3.0.0 4710 [008] 19187729.668886: sched:sched_stat_blocked: comm=jbd2/dm-2-8 pid=697 delay=120641 [ns] 
     ffffffff810a08d8 enqueue_sleeper ([kernel.kallsyms]) 
     ffffffff810a08d8 enqueue_sleeper ([kernel.kallsyms]) 
     ffffffff810a756a enqueue_entity ([kernel.kallsyms]) 
     ffffffff810a7e83 enqueue_task_fair ([kernel.kallsyms]) 
     ffffffff810967b1 ttwu_activate ([kernel.kallsyms]) 
     ffffffff81096983 ttwu_do_activate ([kernel.kallsyms]) 
     ffffffff8109819a ttwu_queue ([kernel.kallsyms]) 
     ffffffff810983fe try_to_wake_up ([kernel.kallsyms]) 
     ffffffff810ada66 autoremove_wake_function ([kernel.kallsyms]) 
     ffffffff810ad8fa __wake_up_common ([kernel.kallsyms]) 
     ffffffff810addb8 __wake_up ([kernel.kallsyms]) 
     ffffffff810ade11 __wake_up_bit ([kernel.kallsyms]) 
     ffffffff81260fcb ext4_finish_bio ([kernel.kallsyms]) 
     ffffffff812617df ext4_end_bio ([kernel.kallsyms]) 
     ffffffff8131b433 blk_update_request ([kernel.kallsyms]) 
     ffffffff8131b5b7 blk_update_bidi_request ([kernel.kallsyms]) 
     ffffffff8131c9af blk_end_bidi_request ([kernel.kallsyms]) 
     ffffffff8148f1f0 scsi_io_completion ([kernel.kallsyms]) 
     ffffffff813263bb blk_done_softirq ([kernel.kallsyms]) 
     ffffffff8106af9c __do_softirq ([kernel.kallsyms]) 
     ffffffff8106b1e5 irq_exit ([kernel.kallsyms]) 
     ffffffff816399fa do_IRQ ([kernel.kallsyms]) 
     ffffffff8163796d ret_from_intr ([kernel.kallsyms]) 
        487f77 [unknown] ([unknown]) 
        487f77 meetmaker__user_counters_get (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        505cff gpbrpc_exec (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        4eb45c ipc_game_loop (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        4ed48a game (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        48ebe3 service_late_init (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
        47371a main (/local/meetmaker/bin/meetmaker-3.0.0_2724) 
      7fd3cc391c36 __libc_start_main (/lib64/libc-2.11.3.so) 

Pour autant que je comprends cette sortie de perf, il est jbd thread noyau qui est dans l'état D et préempté mon processus meetmaker. Ce n'est pas que le processus meetmaker est entré dans l'état D, n'est-ce pas?

Donc ce n'est pas ce que je cherche. Même si j'ai donné -p argument à perf, cela m'a donné un autre processus qui ne m'intéresse pas.

Ai-je raison? Est-ce la meilleure façon de déterminer quand et pourquoi un processus particulier entre en état «D»?

Answer 1

perf est le mauvais outil ici. Vous pouvez suivre ces transitions d'état avec systemtap.

Cependant, il n'y a pas de règle magique. Vous devez étudier chaque lieu séparément.

Answer 2

D état est un état du noyau entré quand un processus du noyau doit attendre un événement de pilote pour sûr qui va se passer, et ne peut pas accepter des signaux (même les non ignorables, comme SIGKILL ou SIGSTOP). Un signal sort normalement du flux normal du programme, donc c'est assez courant dans l'espace utilisateur (vous en tant qu'utilisateur voulez pouvoir interrompre vos programmes) mais dans l'espace noyau il y a des processus (liés au travail du driver) qui conduiraient le driver les données dans un état instable si elles sont autorisées à être interrompues (supposons que vous programmez un périphérique pour vous interrompre et que vous ne soyez pas là pour confirmer l'interruption), le noyau a cet état pour cela (D signifie Driver état? Quelqu'un peut-il le confirmer?). Supposons que vous lisez des données de disque et que vous ayez programmé la puce du contrôleur pour vous interrompre, vous devez attendre que le disque transfère toutes les données du bloc dans les tampons du noyau et vous interrompre. L'interruption est à venir dans quelques millisecs ou usecs, à coup sûr ... mais si vous interrompez le processus au milieu il n'y aurait aucun processus pour se réveiller, il n'y a rien à reconnaître l'interruption de l'appareil et l'appareil sera bloqué. L'état D dépend du pilote. Le noyau entre dans cet état sur une opération durable lorsqu'il entre dans le code du pilote (les auteurs de pilotes appellent spécifiquement wait__non_interruptable functions pour l'obtenir) pour effectuer une tâche spécifique.

Ainsi, il n'est pas interruptible, vous devez attendre qu'il sorte par lui-même. Cela signifie que vous ne pouvez pas tuer le processus de l'espace utilisateur de toute façon et que l'une de ces choses verrouillant votre système signifie normalement un bug de pilote.