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

[zhangyanfei]

于 2012年11月02日 05:09, Dave Anderson 写道:
> 
> 
> ----- Original Message -----
> 
>>>> My suggestion re: a new -g flag would have it applicable to both CFS and RT
>>>> run queues (even though the RT groups are currently being shown).  I was
>>>> thinking that it might be safest to have "runq" (with no argument) to just
>>>> display a simple list of tasks, and only show group information with -g.
>>>> Are you suggesting that -g would only apply to throttled cfs_rqs/rt_rqs?
>>>>
>>>
>>> nop, '-g' is ok to show all rqs with group information.
>>>
>>> I rewrote the patch by adding option '-g' to runq and not changing any behaviour of
>>> the runq (with no argument).
>>>
>>> TODO:
>>> 1. The help info about the -g option.
>>>
>>> I still have a suggestion: when we dump cfs_rq, we don't dump it hierarchically,
>>> but for the current rt_rq, we dump it hierarchically with group info.
>>> So could I make another patch to remove the rt_rq hierarchy, just make it
>>> displayed identical with cfs_rq display.(For -g will display group info for both rt_rq
>>> and cfs_rq)
>>
>> Yes, that's exactly what I was suggesting.
>>
>> I worry about the large number of kernel structure.member declarations that the
>> command depends upon, because if just one of them changes, it breaks the command.
>> So it would be preferable if the "runq" command (with no arguments) would only use
>> a minimal set of structure.member offsets.

I made two new offset-init functions for runq:

    static void cfs_rq_offset_init(void);
    static void task_group_offset_init(void);

the first one is used for runq with no arguments. The extra offset init for runq -g
is in the second one. So nothing changed with the original runq after applying the
runq -g patch.

>>
>> Thanks,
>>   Dave
> 
> And to follow up, I'm still running tests (and will do so overnight) on your latest
> patch, but I immediately seen this on any 2.6.30, 2.6.31 or 2.6.32 kernel, and on
> some 2.6.36 and 2.6.38 kernels, where "runq -g" fails like this:
> 
>   crash> runq -g
>   runq: invalid kernel virtual address: 0  type: "dentry"
>   crash>
>   

As you have pointed in another mail, this is fixed in patch v2, I think.

> And we certainly want to keep the group information separate from
> the normal "runq" command.  Here on a "live" 4 cpu Fedora 3.6.3 kernel,
> the command output exceeds 1000 lines!  I'm pretty sure that most
> people will *not* want to see all of this:
> 
>   crash> runq -g
>   CPU 0
>     CURRENT: PID: 0      TASK: ffffffff81c13420  COMMAND: "swapper/0"
>     RT PRIO_ARRAY: ffff88021e213e28
>        [100] GROUP RT PRIO_ARRAY: ffff88020db22000 <system>
>              [100] GROUP RT PRIO_ARRAY: ffff8801f8180000 <udisks2.service>
>                    [no tasks queued]

<snip>

>              [no tasks queued]
>        GROUP CFS RB_ROOT: ffff88020a844128
>           [no tasks queued]
>   crash> 
> 
> In fact, it's difficult to actually find a real *task* that is on
> a run queue from among all of the empty "[no tasks queued]" groups!
> 

I've noticed this in the first patch and patch V2 has fixed this.

So I attach the new patch v2 version for runq -g. If you still find
any bug in your tests or have any suggestion about it, that's very
helpful.

TODO:
1. The help info about the -g option.
2. Change rt_rq tasks displayed non-hierarchically.

Many thanks
Zhang


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-add-g-option-for-runq-v2.patch
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20121105/fab8341c/attachment.ksh>