我正在玩perf以了解如何弄清楚为什么进程进入“D”(不间断睡眠)状态。
我正在使用perf命令:
perf record -g -p 4710 -e sched:sched_stat_iowait,sched:sched_stat_blocked sleep 60
其中4710
是我的流程pid meetmaker
。
然后我正在查看perf script
输出
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)
据我理解这个perf输出,它是jbd
内核线程处于D状态并且它抢占了我的meetmaker
进程。 meetmaker
进程不是进入D状态,对吧?
所以这不是我想要的。虽然我给了perf -p
参数,但它给了我另一个我不感兴趣的过程。
我是对的吗?
这是了解任何特定进程何时以及为何进入“D”状态的最佳方法吗?
答案 0 :(得分:0)
perf是错误的工具。您可以使用systemtap跟踪此类状态转换。
然而,没有神奇的规则。你必须分别调查每个地方。
答案 1 :(得分:0)
D
状态是一个内核状态,当某个内核进程必须等待某些肯定会发生的驱动程序事件时才会进入,并且不能接受信号(即使是不可忽略的信号,如SIGKILL
或SIGSTOP
)。信号通常会超出正常的程序流程,所以它在用户空间中有些常见(您作为用户希望能够中断您的程序)但在内核空间中存在可引导驱动程序的进程(与驱动程序工作相关)如果允许被中断,则处于不稳定状态的数据(假设你编程某个设备来中断你并且你不在那里确认中断。你将获得设备锁定),所以内核具有这种状态({{1代表D
状态?有人可以证实吗?)。假设您正在读取某些磁盘数据,并且您已将控制器芯片编程为中断您,则必须等待磁盘将所有块数据传输到内核缓冲区并中断您。中断是以毫微秒或微秒为单位,但是如果你在中间中断进程就没有进程唤醒,没有什么可以确认设备中断,设备将被阻止。 Driver
状态是驱动程序所依赖的。当内核输入驱动程序代码(驱动程序编写者专门调用wait__non_interruptable函数来获取它)来执行特定任务时,内核在持久操作上进入此状态。
因此,它不可中断,你必须等待它自己出去。这意味着你无论如何都无法从用户空间中杀死进程,并且正常情况下锁定你的系统会导致一些驱动程序错误。