[Crash-utility] [PATCH] runq: make tasks in throttled cfs_rqs/rt_rqs displayed

zhangyanfei zhangyanfei at cn.fujitsu.com
Tue Nov 13 08:23:25 UTC 2012


于 2012年11月13日 04:15, Dave Anderson 写道:
> 
> 
> ----- Original Message -----
> 
>>> Secondly, another question I have is the meaning of the command's output.
>>>
>>> First, consider this "runq" output:
>>>
>>>  crash> runq
>>>  CPU 0 RUNQUEUE: ffff8800090436c0
>>>    CURRENT: PID: 588    TASK: ffff88007e4877a0  COMMAND: "udevd"
>>>    RT PRIO_ARRAY: ffff8800090437c8
>>>       [no tasks queued]
>>>    CFS RB_ROOT: ffff880009043740
>>>       [118] PID: 2110   TASK: ffff88007d470860  COMMAND: "check-cdrom.sh"
>>>       [118] PID: 2109   TASK: ffff88007f1247a0  COMMAND: "check-cdrom.sh"
>>>       [118] PID: 2114   TASK: ffff88007f20e080  COMMAND: "udevd"
>>>  
>>>  CPU 1 RUNQUEUE: ffff88000905b6c0
>>>    CURRENT: PID: 2113   TASK: ffff88007e8ac140  COMMAND: "udevd"
>>>    RT PRIO_ARRAY: ffff88000905b7c8
>>>       [no tasks queued]
>>>    CFS RB_ROOT: ffff88000905b740
>>>       [118] PID: 2092   TASK: ffff88007d7a4760  COMMAND: "MAKEDEV"
>>>       [118] PID: 1983   TASK: ffff88007e59f140  COMMAND: "udevd"
>>>       [118] PID: 2064   TASK: ffff88007e40f7a0  COMMAND: "udevd"
>>>       [115] PID: 2111   TASK: ffff88007e4278a0  COMMAND: "kthreadd"
>>>  crash>
>>>
>>> In the above case, the per-cpu "rq" structure addresses are shown as:
>>>
>>>  CPU 0 RUNQUEUE: ffff8800090436c0
>>>  CPU 1 RUNQUEUE: ffff88000905b6c0
>>>
>>> And embedded in each of the rq structures above are these two rb_root
>>> structures:
>>>
>>>    CFS RB_ROOT: ffff880009043740  (embedded in rq @ffff8800090436c0)
>>>    CFS RB_ROOT: ffff88000905b740  (embedded in rq @ffff88000905b6c0)
>>>
>>> And starting at those rb_root structures, the tree of tasks are
>>> dumped.
>>>
>>> Now, your "runq -q" option doesn't show any "starting point" structure
>>> address, but rather they just show "CPU 0" and "CPU 1":
>>>  
>>>  crash> runq -g
>>>  CPU 0
>>>    CURRENT: PID: 588    TASK: ffff88007e4877a0  COMMAND: "udevd"
>>>    RT PRIO_ARRAY: ffff8800090437c8
>>>       [no tasks queued]
>>>    CFS RB_ROOT: ffff880009093548
>>>       [118] PID: 2110   TASK: ffff88007d470860  COMMAND: "check-cdrom.sh"
>>>       [118] PID: 2109   TASK: ffff88007f1247a0  COMMAND: "check-cdrom.sh"
>>>       [118] PID: 2114   TASK: ffff88007f20e080  COMMAND: "udevd"
>>>  
>>>  CPU 1
>>>    CURRENT: PID: 2113   TASK: ffff88007e8ac140  COMMAND: "udevd"
>>>    RT PRIO_ARRAY: ffff88000905b7c8
>>>       [no tasks queued]
>>>    CFS RB_ROOT: ffff880009093548
>>>       [118] PID: 2092   TASK: ffff88007d7a4760  COMMAND: "MAKEDEV"
>>>       [118] PID: 1983   TASK: ffff88007e59f140  COMMAND: "udevd"
>>>       [118] PID: 2064   TASK: ffff88007e40f7a0  COMMAND: "udevd"
>>>       [115] PID: 2111   TASK: ffff88007e4278a0  COMMAND: "kthreadd"
>>>  crash>
>>>  
>>> I would think that there might be a useful address of a per-cpu
>>> structure that could be shown there as well?
>>
>> OK, this is added.
> 
> OK, but now your addition just mimics the "runq" output.  You are just
> calculating the CFS "runq" address for display, but that address does 
> not passed to (or used by) either dump_tasks_in_task_group_rt_rq()
> or dump_tasks_in_task_group_cfs_rq().
> 
> I was suggesting that you display per-cpu addresses generated from the 
> init_task_group/root_task_group task_group structures.  Wouldn't it make
> more sense for it to show both the per-cpu "rt_rq" and "cfs_rq" addresses?
> 
> In other words, maybe something like:
> 
>  CPU 0  TASK_GROUP RT_RQ: ffff88021e213e28  TASK_GROUP CFS_RQ: ffff88021e213d30
>    CURRENT: ...
> 

OK, fixed.

Thanks
Zhang
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-add-g-option-for-runq-v6.patch
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20121113/70271d8e/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0002-add-help-info-for-runq-g-v3.patch
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20121113/70271d8e/attachment-0001.ksh>


More information about the Crash-utility mailing list