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

----- 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.

> > 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>

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]

[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!