3:52 p.m.
Hi,
We're debugging an in-house application that makes use of hard limit extensively. We
ran into a lot of timing windows (all our own making) and we use runq -g command a lot.
The current runq -g display only the RBROOT pointer. It really is a bit inconvenient to
traverse the task_group hierarchy. It would be nice to have the command also display the
corresponding task_group, cfs_rq pointer (at a minimum). Since the way we crash the system
by messing up the nr_running and h_nr_running, so we also display those two fields at the
same time. Here's an example of before and after.
CPU 4
CURRENT: PID: 0 TASK: ffff8840668c0380 COMMAND: "swapper"
TASK_GROUP RT_RQ: ffff8800027d3820
RT PRIO_ARRAY: ffff8800027d3820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800027d36e0
CFS RB_ROOT: ffff8800027d3710
GROUP CFS RB_ROOT: ffff883ff69bcc30 <TDAT>
GROUP CFS RB_ROOT: ffff884006290e30 <User>
GROUP CFS RB_ROOT: ffff88400641c430 <TDWMVP1>
GROUP CFS RB_ROOT: ffff88400646b030 <ServDown1:0>
GROUP CFS RB_ROOT: ffff884006492630 <ServOrder1:1>
GROUP CFS RB_ROOT: ffff883ff058fe30 <TDWMWD57> (THROTTLED)
GROUP CFS RB_ROOT: ffff88047889ee30 <S:WD:3d:35fa>
[120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND:
"actmain"
<<< more throttled groups removed >>>
CPU 4
CURRENT: PID: 0 CFS: ffff8800027d36e0 TASK: ffff8840668c0380 COMMAND:
"swapper"
TASK_GROUP RT_RQ: ffff8800027d3820
RT PRIO_ARRAY: ffff8800027d3820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800027d36e0
CFS RB_ROOT: ffff8800027d3710
GROUP: ffff88405394d000 CFS: ffff883ff69bcc00 RB_ROOT: ffff883ff69bcc30 <TDAT>
(0 0)
GROUP: ffff88405906c400 CFS: ffff884006290e00 RB_ROOT: ffff884006290e30
<User> (0 0)
GROUP: ffff884055081000 CFS: ffff88400641c400 RB_ROOT: ffff88400641c430
<TDWMVP1> (0 0)
GROUP: ffff884055081c00 CFS: ffff88400646b000 RB_ROOT: ffff88400646b030
<ServDown1:0> (0 0)
GROUP: ffff8840580fd400 CFS: ffff884006492600 RB_ROOT: ffff884006492630
<ServOrder1:1> (0 0)
GROUP: ffff884058f58c00 CFS: ffff883ff058fe00 RB_ROOT:
ffff883ff058fe30 <TDWMWD57> (7 9) (THROTTLED)
GROUP: ffff8808fb976000 CFS: ffff88047889ee00 RB_ROOT:
ffff88047889ee30 <S:WD:3d:35fa> (1 1)
[120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND:
"actmain"
<<< more throttled groups removed >>>
I have attached the patch we use to display additional information. Could you please take
a look at my proposal to see if it is possible that you include this kind of display
format.
Thanks,
Anthony
9:41 a.m.
Qiao, Daisuke and Zhang,
Can you guys comment on this patch? It looks reasonable enough.
Thanks,
Dave
----- Original Message -----
Hi,
We’re debugging an in-house application that makes use of hard limit
extensively. We ran into a lot of timing windows (all our own making) and we
use runq -g command a lot. The current runq -g display only the RBROOT
pointer. It really is a bit inconvenient to traverse the task_group
hierarchy. It would be nice to have the command also display the
corresponding task_group, cfs_rq pointer (at a minimum). Since the way we
crash the system by messing up the nr_running and h_nr_running, so we also
display those two fields at the same time. Here’s an example of before and
after.
CPU 4
CURRENT: PID: 0 TASK: ffff8840668c0380 COMMAND: "swapper"
TASK_GROUP RT_RQ: ffff8800027d3820
RT PRIO_ARRAY: ffff8800027d3820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800027d36e0
CFS RB_ROOT: ffff8800027d3710
GROUP CFS RB_ROOT: ffff883ff69bcc30 <TDAT>
GROUP CFS RB_ROOT: ffff884006290e30 <User>
GROUP CFS RB_ROOT: ffff88400641c430 <TDWMVP1>
GROUP CFS RB_ROOT: ffff88400646b030 <ServDown1:0>
GROUP CFS RB_ROOT: ffff884006492630 <ServOrder1:1>
GROUP CFS RB_ROOT: ffff883ff058fe30 <TDWMWD57> (THROTTLED)
GROUP CFS RB_ROOT: ffff88047889ee30 <S:WD:3d:35fa>
[120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND: "actmain"
<<< more throttled groups removed >>>
CPU 4
CURRENT: PID: 0 CFS: ffff8800027d36e0 TASK: ffff8840668c0380 COMMAND:
"swapper"
TASK_GROUP RT_RQ: ffff8800027d3820
RT PRIO_ARRAY: ffff8800027d3820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800027d36e0
CFS RB_ROOT: ffff8800027d3710
GROUP: ffff88405394d000 CFS: ffff883ff69bcc00 RB_ROOT: ffff883ff69bcc30
<TDAT> (0 0)
GROUP: ffff88405906c400 CFS: ffff884006290e00 RB_ROOT: ffff884006290e30
<User> (0 0)
GROUP: ffff884055081000 CFS: ffff88400641c400 RB_ROOT: ffff88400641c430
<TDWMVP1> (0 0)
GROUP: ffff884055081c00 CFS: ffff88400646b000 RB_ROOT: ffff88400646b030
<ServDown1:0> (0 0)
GROUP: ffff8840580fd400 CFS: ffff884006492600 RB_ROOT: ffff884006492630
<ServOrder1:1> (0 0)
GROUP: ffff884058f58c00 CFS: ffff883ff058fe00 RB_ROOT: ffff883ff058fe30
<TDWMWD57> (7 9) (THROTTLED)
GROUP: ffff8808fb976000 CFS: ffff88047889ee00 RB_ROOT: ffff88047889ee30
<S:WD:3d:35fa> (1 1)
[120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND: "actmain"
<<< more throttled groups removed >>>
I have attached the patch we use to display additional information. Could you
please take a look at my proposal to see if it is possible that you include
this kind of display format.
Thanks,
Anthony
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
2:46 p.m.
----- Original Message -----
Hi,
We’re debugging an in-house application that makes use of hard limit
extensively. We ran into a lot of timing windows (all our own making) and we
use runq -g command a lot. The current runq -g display only the RBROOT
pointer. It really is a bit inconvenient to traverse the task_group
hierarchy. It would be nice to have the command also display the
corresponding task_group, cfs_rq pointer (at a minimum). Since the way we
crash the system by messing up the nr_running and h_nr_running, so we also
display those two fields at the same time. Here’s an example of before and
after.
CPU 4
CURRENT: PID: 0 TASK: ffff8840668c0380 COMMAND: "swapper"
TASK_GROUP RT_RQ: ffff8800027d3820
RT PRIO_ARRAY: ffff8800027d3820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800027d36e0
CFS RB_ROOT: ffff8800027d3710
GROUP CFS RB_ROOT: ffff883ff69bcc30 <TDAT>
GROUP CFS RB_ROOT: ffff884006290e30 <User>
GROUP CFS RB_ROOT: ffff88400641c430 <TDWMVP1>
GROUP CFS RB_ROOT: ffff88400646b030 <ServDown1:0>
GROUP CFS RB_ROOT: ffff884006492630 <ServOrder1:1>
GROUP CFS RB_ROOT: ffff883ff058fe30 <TDWMWD57> (THROTTLED)
GROUP CFS RB_ROOT: ffff88047889ee30 <S:WD:3d:35fa>
[120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND: "actmain"
<<< more throttled groups removed >>>
CPU 4
CURRENT: PID: 0 CFS: ffff8800027d36e0 TASK: ffff8840668c0380 COMMAND:
"swapper"
TASK_GROUP RT_RQ: ffff8800027d3820
RT PRIO_ARRAY: ffff8800027d3820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800027d36e0
CFS RB_ROOT: ffff8800027d3710
GROUP: ffff88405394d000 CFS: ffff883ff69bcc00 RB_ROOT: ffff883ff69bcc30
<TDAT> (0 0)
GROUP: ffff88405906c400 CFS: ffff884006290e00 RB_ROOT: ffff884006290e30
<User> (0 0)
GROUP: ffff884055081000 CFS: ffff88400641c400 RB_ROOT: ffff88400641c430
<TDWMVP1> (0 0)
GROUP: ffff884055081c00 CFS: ffff88400646b000 RB_ROOT: ffff88400646b030
<ServDown1:0> (0 0)
GROUP: ffff8840580fd400 CFS: ffff884006492600 RB_ROOT: ffff884006492630
<ServOrder1:1> (0 0)
GROUP: ffff884058f58c00 CFS: ffff883ff058fe00 RB_ROOT: ffff883ff058fe30
<TDWMWD57> (7 9) (THROTTLED)
GROUP: ffff8808fb976000 CFS: ffff88047889ee00 RB_ROOT: ffff88047889ee30
<S:WD:3d:35fa> (1 1)
[120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND: "actmain"
<<< more throttled groups removed >>>
I have attached the patch we use to display additional information. Could you
please take a look at my proposal to see if it is possible that you include
this kind of display format.
Thanks,
Anthony
A couple quick observations...
Adding the CFS: address makes sense, but besides you and me and whoever
reads the patch/code, how would anybody know what the two numbers inside
the parentheses mean? It could be documented in the help page, but I
wonder if it could be made more obvious somehow?
Anyway, I ran a test on a sample set of vmcores, and this addition
will only work with relevant kernel versions. For example, in these
four dumpfiles (and therefore their kernel versions), the command
fails because the cfs_rq.h_nr_running member does not exist:
2.6.38.2-9.fc15:
CPU 0
CURRENT: PID: 1180 CFS: ffff880037ef1b00 TASK: ffff88003bea2e40 COMMAND:
"crash"
TASK_GROUP RT_RQ: ffff88003fc13988
RT PRIO_ARRAY: ffff88003fc13988
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88003fc138b0
CFS RB_ROOT: ffff88003fc138d8
GROUP: ffff88003c610a00 CFS: ffff880037ef1b00 RB_ROOT: ffff880037ef1b28
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
2.6.40.4-5.fc15:
CPU 1
CURRENT: PID: 1341 CFS: ffff880037592f00 TASK: ffff880037409730 COMMAND:
"crash"
TASK_GROUP RT_RQ: ffff88003fc92690
RT PRIO_ARRAY: ffff88003fc92690
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88003fc925b0
CFS RB_ROOT: ffff88003fc925d8
GROUP: ffff88003a84b800 CFS: ffff880037592f00 RB_ROOT: ffff880037592f28
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
2.6.32-131.0.15.el6:
CPU 0
CURRENT: PID: 28263 CFS: ffff8800794b7140 TASK: ffff880037aaa040 COMMAND:
"loop.ABA"
TASK_GROUP RT_RQ: ffff88000a216098
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88000a215fe8
CFS RB_ROOT: ffff88000a216010
GROUP: ffff8800785bc200 CFS: ffff8800784d7c80 RB_ROOT: ffff8800784d7ca8 <A>
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
3.1.7-1.fc16:
CPU 2
CURRENT: PID: 1495 CFS: ffff8800277f8500 TASK: ffff880037a60000 COMMAND:
"crash"
TASK_GROUP RT_RQ: ffff88003e2532d0
RT PRIO_ARRAY: ffff88003e2532d0
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88003e2531f0
CFS RB_ROOT: ffff88003e253218
GROUP: ffff88002722b000 CFS: ffff8800277f8500 RB_ROOT: ffff8800277f8528
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
So you'll need to check VALID_MEMBER(cfs_rq_h_nr_running) before attempting
to print it, and maybe just show the cfs_rq.nr_running value.
When adding new items to the offset_table, they should be added to the
end of the structure so that extension modules will continue to be able
to access any offsets as expected without having to be re-compiled.
But you can display the new item in dump_offset_table() wherever you'd
like, typically grouped with similar/associated items -- although in your
patch you did this:
+ fprintf(fp, " cfs_rq_nr_running: %ld\n",
+ OFFSET(cfs_rq_nr_running));
+ fprintf(fp, " cfs_rq_h_nr_running: %ld\n",
+ OFFSET(cfs_rq_h_nr_running));
The previously-existing cfs_rq_nr_running display already exists,
so I suggest that you just move your new cfs_rq_h_nr_running display
underneath it. (and please line up the "help -o" output of the new
item as well).
Dave
7:41 p.m.
New subject: patch for slight modification to runq -g command
Dave,
Thanks for the comment. I'll rework the patch.
Anthony
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
bounces(a)redhat.com] On Behalf Of Dave Anderson
Sent: Thursday, October 17, 2013 12:46 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] FW: patch for slight modification to runq -g
command
----- Original Message -----
>
>
>
>
> Hi,
>
>
>
> We’re debugging an in-house application that makes use of hard limit
> extensively. We ran into a lot of timing windows (all our own making)
and we
> use runq -g command a lot. The current runq -g display only the
RBROOT
> pointer. It really is a bit inconvenient to traverse the task_group
> hierarchy. It would be nice to have the command also display the
> corresponding task_group, cfs_rq pointer (at a minimum). Since the
way we
> crash the system by messing up the nr_running and h_nr_running, so
we also
> display those two fields at the same time. Here’s an example of before
and
> after.
>
>
>
> CPU 4
>
> CURRENT: PID: 0 TASK: ffff8840668c0380 COMMAND: "swapper"
>
> TASK_GROUP RT_RQ: ffff8800027d3820
>
> RT PRIO_ARRAY: ffff8800027d3820
>
> [no tasks queued]
>
> TASK_GROUP CFS_RQ: ffff8800027d36e0
>
> CFS RB_ROOT: ffff8800027d3710
>
> GROUP CFS RB_ROOT: ffff883ff69bcc30 <TDAT>
>
> GROUP CFS RB_ROOT: ffff884006290e30 <User>
>
> GROUP CFS RB_ROOT: ffff88400641c430 <TDWMVP1>
>
> GROUP CFS RB_ROOT: ffff88400646b030 <ServDown1:0>
>
> GROUP CFS RB_ROOT: ffff884006492630 <ServOrder1:1>
>
> GROUP CFS RB_ROOT: ffff883ff058fe30 <TDWMWD57> (THROTTLED)
>
> GROUP CFS RB_ROOT: ffff88047889ee30 <S:WD:3d:35fa>
>
> [120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND: "actmain"
>
> <<< more throttled groups removed >>>
>
>
>
> CPU 4
>
> CURRENT: PID: 0 CFS: ffff8800027d36e0 TASK: ffff8840668c0380
COMMAND:
> "swapper"
>
> TASK_GROUP RT_RQ: ffff8800027d3820
>
> RT PRIO_ARRAY: ffff8800027d3820
>
> [no tasks queued]
>
> TASK_GROUP CFS_RQ: ffff8800027d36e0
>
> CFS RB_ROOT: ffff8800027d3710
>
> GROUP: ffff88405394d000 CFS: ffff883ff69bcc00 RB_ROOT:
ffff883ff69bcc30
> <TDAT> (0 0)
>
> GROUP: ffff88405906c400 CFS: ffff884006290e00 RB_ROOT:
ffff884006290e30
> <User> (0 0)
>
> GROUP: ffff884055081000 CFS: ffff88400641c400 RB_ROOT:
ffff88400641c430
> <TDWMVP1> (0 0)
>
> GROUP: ffff884055081c00 CFS: ffff88400646b000 RB_ROOT:
ffff88400646b030
> <ServDown1:0> (0 0)
>
> GROUP: ffff8840580fd400 CFS: ffff884006492600 RB_ROOT:
ffff884006492630
> <ServOrder1:1> (0 0)
>
> GROUP: ffff884058f58c00 CFS: ffff883ff058fe00 RB_ROOT:
ffff883ff058fe30
> <TDWMWD57> (7 9) (THROTTLED)
>
> GROUP: ffff8808fb976000 CFS: ffff88047889ee00 RB_ROOT:
ffff88047889ee30
> <S:WD:3d:35fa> (1 1)
>
> [120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND: "actmain"
>
> <<< more throttled groups removed >>>
>
>
>
> I have attached the patch we use to display additional information.
Could you
> please take a look at my proposal to see if it is possible that you include
> this kind of display format.
>
>
>
> Thanks,
>
> Anthony
A couple quick observations...
Adding the CFS: address makes sense, but besides you and me and
whoever
reads the patch/code, how would anybody know what the two numbers
inside
the parentheses mean? It could be documented in the help page, but I
wonder if it could be made more obvious somehow?
Anyway, I ran a test on a sample set of vmcores, and this addition
will only work with relevant kernel versions. For example, in these
four dumpfiles (and therefore their kernel versions), the command
fails because the cfs_rq.h_nr_running member does not exist:
2.6.38.2-9.fc15:
CPU 0
CURRENT: PID: 1180 CFS: ffff880037ef1b00 TASK: ffff88003bea2e40
COMMAND: "crash"
TASK_GROUP RT_RQ: ffff88003fc13988
RT PRIO_ARRAY: ffff88003fc13988
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88003fc138b0
CFS RB_ROOT: ffff88003fc138d8
GROUP: ffff88003c610a00 CFS: ffff880037ef1b00 RB_ROOT:
ffff880037ef1b28
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
2.6.40.4-5.fc15:
CPU 1
CURRENT: PID: 1341 CFS: ffff880037592f00 TASK: ffff880037409730
COMMAND: "crash"
TASK_GROUP RT_RQ: ffff88003fc92690
RT PRIO_ARRAY: ffff88003fc92690
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88003fc925b0
CFS RB_ROOT: ffff88003fc925d8
GROUP: ffff88003a84b800 CFS: ffff880037592f00 RB_ROOT:
ffff880037592f28
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
2.6.32-131.0.15.el6:
CPU 0
CURRENT: PID: 28263 CFS: ffff8800794b7140 TASK: ffff880037aaa040
COMMAND: "loop.ABA"
TASK_GROUP RT_RQ: ffff88000a216098
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88000a215fe8
CFS RB_ROOT: ffff88000a216010
GROUP: ffff8800785bc200 CFS: ffff8800784d7c80 RB_ROOT:
ffff8800784d7ca8 <A>
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
3.1.7-1.fc16:
CPU 2
CURRENT: PID: 1495 CFS: ffff8800277f8500 TASK: ffff880037a60000
COMMAND: "crash"
TASK_GROUP RT_RQ: ffff88003e2532d0
RT PRIO_ARRAY: ffff88003e2532d0
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88003e2531f0
CFS RB_ROOT: ffff88003e253218
GROUP: ffff88002722b000 CFS: ffff8800277f8500 RB_ROOT:
ffff8800277f8528
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
So you'll need to check VALID_MEMBER(cfs_rq_h_nr_running) before
attempting
to print it, and maybe just show the cfs_rq.nr_running value.
When adding new items to the offset_table, they should be added to
the
end of the structure so that extension modules will continue to be able
to access any offsets as expected without having to be re-compiled.
But you can display the new item in dump_offset_table() wherever
you'd
like, typically grouped with similar/associated items -- although in your
patch you did this:
+ fprintf(fp, " cfs_rq_nr_running: %ld\n",
+ OFFSET(cfs_rq_nr_running));
+ fprintf(fp, " cfs_rq_h_nr_running: %ld\n",
+ OFFSET(cfs_rq_h_nr_running));
The previously-existing cfs_rq_nr_running display already exists,
so I suggest that you just move your new cfs_rq_h_nr_running display
underneath it. (and please line up the "help -o" output of the new
item as well).
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
7:40 p.m.
New subject: patch for slight modification to runq -g command
Hi Dave,
I have cleaned up the code and added another change. The current
running task is not in the rb tree (rb_root), so run -q displays it like:
CURRENT: PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
TASK_GROUP RT_RQ: ffff880002493820
RT PRIO_ARRAY: ffff880002493820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800024936e0
CFS RB_ROOT: ffff880002493710
GROUP CFS RB_ROOT: ffff882d609ce830 <TDAT>
GROUP CFS RB_ROOT: ffff883f0bcbfa30 <User>
[no tasks queued]
I can understand why the current running task is not displayed.
However, the "-g" option displays all the task_groups the task
belongs to but at the end it shows "[no tasks queued]". That is
just strange. The new change is to display the task that is running like:
CURRENT: PID: 9048 CFS: ffff88039351a800 TASK: ffff8808b07e4200 COMMAND:
"actmain"
TASK_GROUP RT_RQ: ffff880002493820
RT PRIO_ARRAY: ffff880002493820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800024936e0
CFS RB_ROOT: ffff880002493710
GROUP: ffff884052bc9800 CFS_RQ: ffff882d609ce800 RB_ROOT: ffff882d609ce830
<TDAT> nr_running: 1 h_nr_running: 1
GROUP: ffff884058f1d000 CFS_RQ: ffff883f0bcbfa00 RB_ROOT: ffff883f0bcbfa30
<User> nr_running: 1 h_nr_running: 1
[120] PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
Thanks,
Anthony
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
bounces(a)redhat.com] On Behalf Of Dave Anderson
Sent: Thursday, October 17, 2013 12:46 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] FW: patch for slight modification to runq -g
command
----- Original Message -----
>
>
>
>
> Hi,
>
>
>
> We’re debugging an in-house application that makes use of hard limit
> extensively. We ran into a lot of timing windows (all our own making)
and we
> use runq -g command a lot. The current runq -g display only the
RBROOT
> pointer. It really is a bit inconvenient to traverse the task_group
> hierarchy. It would be nice to have the command also display the
> corresponding task_group, cfs_rq pointer (at a minimum). Since the
way we
> crash the system by messing up the nr_running and h_nr_running, so
we also
> display those two fields at the same time. Here’s an example of before
and
> after.
>
>
>
> CPU 4
>
> CURRENT: PID: 0 TASK: ffff8840668c0380 COMMAND: "swapper"
>
> TASK_GROUP RT_RQ: ffff8800027d3820
>
> RT PRIO_ARRAY: ffff8800027d3820
>
> [no tasks queued]
>
> TASK_GROUP CFS_RQ: ffff8800027d36e0
>
> CFS RB_ROOT: ffff8800027d3710
>
> GROUP CFS RB_ROOT: ffff883ff69bcc30 <TDAT>
>
> GROUP CFS RB_ROOT: ffff884006290e30 <User>
>
> GROUP CFS RB_ROOT: ffff88400641c430 <TDWMVP1>
>
> GROUP CFS RB_ROOT: ffff88400646b030 <ServDown1:0>
>
> GROUP CFS RB_ROOT: ffff884006492630 <ServOrder1:1>
>
> GROUP CFS RB_ROOT: ffff883ff058fe30 <TDWMWD57> (THROTTLED)
>
> GROUP CFS RB_ROOT: ffff88047889ee30 <S:WD:3d:35fa>
>
> [120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND: "actmain"
>
> <<< more throttled groups removed >>>
>
>
>
> CPU 4
>
> CURRENT: PID: 0 CFS: ffff8800027d36e0 TASK: ffff8840668c0380
COMMAND:
> "swapper"
>
> TASK_GROUP RT_RQ: ffff8800027d3820
>
> RT PRIO_ARRAY: ffff8800027d3820
>
> [no tasks queued]
>
> TASK_GROUP CFS_RQ: ffff8800027d36e0
>
> CFS RB_ROOT: ffff8800027d3710
>
> GROUP: ffff88405394d000 CFS: ffff883ff69bcc00 RB_ROOT:
ffff883ff69bcc30
> <TDAT> (0 0)
>
> GROUP: ffff88405906c400 CFS: ffff884006290e00 RB_ROOT:
ffff884006290e30
> <User> (0 0)
>
> GROUP: ffff884055081000 CFS: ffff88400641c400 RB_ROOT:
ffff88400641c430
> <TDWMVP1> (0 0)
>
> GROUP: ffff884055081c00 CFS: ffff88400646b000 RB_ROOT:
ffff88400646b030
> <ServDown1:0> (0 0)
>
> GROUP: ffff8840580fd400 CFS: ffff884006492600 RB_ROOT:
ffff884006492630
> <ServOrder1:1> (0 0)
>
> GROUP: ffff884058f58c00 CFS: ffff883ff058fe00 RB_ROOT:
ffff883ff058fe30
> <TDWMWD57> (7 9) (THROTTLED)
>
> GROUP: ffff8808fb976000 CFS: ffff88047889ee00 RB_ROOT:
ffff88047889ee30
> <S:WD:3d:35fa> (1 1)
>
> [120] PID: 27655 TASK: ffff8805078ce2c0 COMMAND: "actmain"
>
> <<< more throttled groups removed >>>
>
>
>
> I have attached the patch we use to display additional information.
Could you
> please take a look at my proposal to see if it is possible that you include
> this kind of display format.
>
>
>
> Thanks,
>
> Anthony
A couple quick observations...
Adding the CFS: address makes sense, but besides you and me and
whoever
reads the patch/code, how would anybody know what the two numbers
inside
the parentheses mean? It could be documented in the help page, but I
wonder if it could be made more obvious somehow?
Anyway, I ran a test on a sample set of vmcores, and this addition
will only work with relevant kernel versions. For example, in these
four dumpfiles (and therefore their kernel versions), the command
fails because the cfs_rq.h_nr_running member does not exist:
2.6.38.2-9.fc15:
CPU 0
CURRENT: PID: 1180 CFS: ffff880037ef1b00 TASK: ffff88003bea2e40
COMMAND: "crash"
TASK_GROUP RT_RQ: ffff88003fc13988
RT PRIO_ARRAY: ffff88003fc13988
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88003fc138b0
CFS RB_ROOT: ffff88003fc138d8
GROUP: ffff88003c610a00 CFS: ffff880037ef1b00 RB_ROOT:
ffff880037ef1b28
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
2.6.40.4-5.fc15:
CPU 1
CURRENT: PID: 1341 CFS: ffff880037592f00 TASK: ffff880037409730
COMMAND: "crash"
TASK_GROUP RT_RQ: ffff88003fc92690
RT PRIO_ARRAY: ffff88003fc92690
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88003fc925b0
CFS RB_ROOT: ffff88003fc925d8
GROUP: ffff88003a84b800 CFS: ffff880037592f00 RB_ROOT:
ffff880037592f28
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
2.6.32-131.0.15.el6:
CPU 0
CURRENT: PID: 28263 CFS: ffff8800794b7140 TASK: ffff880037aaa040
COMMAND: "loop.ABA"
TASK_GROUP RT_RQ: ffff88000a216098
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88000a215fe8
CFS RB_ROOT: ffff88000a216010
GROUP: ffff8800785bc200 CFS: ffff8800784d7c80 RB_ROOT:
ffff8800784d7ca8 <A>
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
3.1.7-1.fc16:
CPU 2
CURRENT: PID: 1495 CFS: ffff8800277f8500 TASK: ffff880037a60000
COMMAND: "crash"
TASK_GROUP RT_RQ: ffff88003e2532d0
RT PRIO_ARRAY: ffff88003e2532d0
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88003e2531f0
CFS RB_ROOT: ffff88003e253218
GROUP: ffff88002722b000 CFS: ffff8800277f8500 RB_ROOT:
ffff8800277f8528
runq: invalid structure member offset: cfs_rq_h_nr_running
FILE: task.c LINE: 7632 FUNCTION: print_group_header_fair()
So you'll need to check VALID_MEMBER(cfs_rq_h_nr_running) before
attempting
to print it, and maybe just show the cfs_rq.nr_running value.
When adding new items to the offset_table, they should be added to
the
end of the structure so that extension modules will continue to be able
to access any offsets as expected without having to be re-compiled.
But you can display the new item in dump_offset_table() wherever
you'd
like, typically grouped with similar/associated items -- although in your
patch you did this:
+ fprintf(fp, " cfs_rq_nr_running: %ld\n",
+ OFFSET(cfs_rq_nr_running));
+ fprintf(fp, " cfs_rq_h_nr_running: %ld\n",
+ OFFSET(cfs_rq_h_nr_running));
The previously-existing cfs_rq_nr_running display already exists,
so I suggest that you just move your new cfs_rq_h_nr_running display
underneath it. (and please line up the "help -o" output of the new
item as well).
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
3:13 p.m.
New subject: patch for slight modification to runq -g command
----- Original Message -----
Hi Dave,
I have cleaned up the code and added another change.
OK thanks -- the patch runs through my sample set of vmcores with no problem.
The current running task is not in the rb tree (rb_root), so run -q
displays it like:
CURRENT: PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
TASK_GROUP RT_RQ: ffff880002493820
RT PRIO_ARRAY: ffff880002493820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800024936e0
CFS RB_ROOT: ffff880002493710
GROUP CFS RB_ROOT: ffff882d609ce830 <TDAT>
GROUP CFS RB_ROOT: ffff883f0bcbfa30 <User>
[no tasks queued]
I can understand why the current running task is not displayed.
However, the "-g" option displays all the task_groups the task
belongs to but at the end it shows "[no tasks queued]". That is
just strange. The new change is to display the task that is running like:
CURRENT: PID: 9048 CFS: ffff88039351a800 TASK: ffff8808b07e4200 COMMAND:
"actmain"
TASK_GROUP RT_RQ: ffff880002493820
RT PRIO_ARRAY: ffff880002493820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800024936e0
CFS RB_ROOT: ffff880002493710
GROUP: ffff884052bc9800 CFS_RQ: ffff882d609ce800 RB_ROOT: ffff882d609ce830
<TDAT> nr_running: 1 h_nr_running: 1
GROUP: ffff884058f1d000 CFS_RQ: ffff883f0bcbfa00 RB_ROOT: ffff883f0bcbfa30
<User> nr_running: 1 h_nr_running: 1
[120] PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
OK -- I guess I understand why it probably makes sense to duplicate the
CURRENT task underneath its own GROUP list -- but if that is done, then
why clutter the CURRENT line with the CFS_RQ address? And it's not clear
to me why in your example above, the CFS address of ffff88039351a800
doesn't show up as the CFS_RQ address above the "actmain" line?
Taking a simple example, I see this:
crash> runq -g
CPU 0
CURRENT: PID: 0 CFS: ffff88000c7d6aa8 TASK: ffffffff8178ba60 COMMAND:
"swapper"
TASK_GROUP RT_RQ: ffff88000c7d6b58
RT PRIO_ARRAY: ffff88000c7d6b58
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88000c7d6aa8
CFS RB_ROOT: ffff88000c7d6ad0
[no tasks queued]
CPU 1
CURRENT: PID: 1268 CFS: ffff88000c9b5aa8 TASK: ffff88002f11c620 COMMAND:
"bash"
TASK_GROUP RT_RQ: ffff88000c9b5b58
RT PRIO_ARRAY: ffff88000c9b5b58
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88000c9b5aa8
CFS RB_ROOT: ffff88000c9b5ad0
[120] PID: 1268 TASK: ffff88002f11c620 COMMAND: "bash"
crash>
Where the newly-interspersed CFS address redundantly shows the TASK_GROUP CFS_RQ
below. But adding the CFS address to the "swapper" line doesn't seem to
make
much sense, or help in any way, since the idle task is a special case that never
gets queued. And since the CFS address in the "bash" line is redundant with
the
TASK_GROUP CFS_RQ below, why bother showing it?
And in a more complicated example, with your patch, the "qemu-kvm" task also
shows up underneath its group:
CPU 0
CURRENT: PID: 3144 CFS: ffff88022aab2600 TASK: ffff88022a446040 COMMAND:
"qemu-kvm"
TASK_GROUP RT_RQ: ffff880133c16148
RT PRIO_ARRAY: ffff880133c16148
[no tasks queued]
TASK_GROUP CFS_RQ: ffff880133c16028
CFS RB_ROOT: ffff880133c16058
GROUP: ffff88012b880800 CFS_RQ: ffff88022ac8f000 RB_ROOT: ffff88022ac8f030
<libvirt> nr_running: 1 h_nr_running: 1
GROUP: ffff88012c078000 CFS_RQ: ffff88022c075000 RB_ROOT: ffff88022c075030
<qemu> nr_running: 1 h_nr_running: 1
GROUP: ffff88012b0fb400 CFS_RQ: ffff88022af94c00 RB_ROOT: ffff88022af94c30
<guest1> nr_running: 1 h_nr_running: 1
GROUP: ffff88022c6bbc00 CFS_RQ: ffff88022aab2600 RB_ROOT: ffff88022aab2630
<vcpu1> nr_running: 1 h_nr_running: 1
[120] PID: 3144 TASK: ffff88022a446040 COMMAND: "qemu-kvm"
And note that its interspersed CFS address of ffff88022aab2600 is redundantly shown
as the CFS_RQ of its GROUP down below.
So I don't understand why your example shows different CFS addresses in the
CURRENT line vs. the GROUP CFS_RQ address above the queued "acctmain" task:
CURRENT: PID: 9048 CFS: ffff88039351a800 TASK: ffff8808b07e4200
COMMAND: "actmain"
TASK_GROUP RT_RQ: ffff880002493820
RT PRIO_ARRAY: ffff880002493820
[no tasks queued]
TASK_GROUP CFS_RQ: ffff8800024936e0
CFS RB_ROOT: ffff880002493710
GROUP: ffff884052bc9800 CFS_RQ: ffff882d609ce800 RB_ROOT: ffff882d609ce830
<TDAT> nr_running: 1 h_nr_running: 1
GROUP: ffff884058f1d000 CFS_RQ: ffff883f0bcbfa00 RB_ROOT: ffff883f0bcbfa30
<User> nr_running: 1 h_nr_running: 1
[120] PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
Am I missing something? Or is there cut-and-paste error?
Dave
3:57 p.m.
New subject: patch for slight modification to runq -g command
Hi Anthony,
With respect to the nr_running and h_nr_running displays, since you
can "see" the number of tasks queued underneath each particular
group, I'm not convinced that it's worth displaying them?
In your first post you mentioned:
Since the way we crash the system by messing up the nr_running and
h_nr_running,
so we also display those two fields at the same time. Here’s an example of before and
after.
Are you saying that you purposely modify those two values in order to force
a crash?
Anyway, I bring this up because their display is kind of ugly, and also because
in the output logs of my test of your patch, I see this particular instance,
where I've got a 3.6.0 kernel where a crash was generated by entering
"echo c > /proc/sysrq-trigger":
crash> bt
PID: 1212 TASK: ffff880035f60000 CPU: 1 COMMAND: "bash"
#0 [ffff88007831fa20] machine_kexec at ffffffff8103e465
#1 [ffff88007831fa90] crash_kexec at ffffffff810c6658
#2 [ffff88007831fb60] oops_end at ffffffff815d5bf8
#3 [ffff88007831fb90] no_context at ffffffff815c7dae
#4 [ffff88007831fbf0] __bad_area_nosemaphore at ffffffff815c7f98
#5 [ffff88007831fc40] bad_area at ffffffff815c81f0
#6 [ffff88007831fc70] do_page_fault at ffffffff815d87d1
#7 [ffff88007831fd80] page_fault at ffffffff815d5025
[exception RIP: sysrq_handle_crash+22]
RIP: ffffffff81388986 RSP: ffff88007831fe38 RFLAGS: 00010092
RAX: 000000000000000f RBX: ffffffff8192dc20 RCX: 00000000000014ff
RDX: 000000000000332f RSI: 0000000000000046 RDI: 0000000000000063
RBP: ffff88007831fe38 R8: ffffffff81b26580 R9: 0000000000000397
R10: 0000000000000002 R11: 0000000000000396 R12: 0000000000000063
R13: 0000000000000286 R14: 0000000000000000 R15: 0000000000000007
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#8 [ffff88007831fe40] __handle_sysrq at ffffffff813890a7
#9 [ffff88007831fe80] write_sysrq_trigger at ffffffff8138915a
#10 [ffff88007831feb0] proc_reg_write at ffffffff811ea879
#11 [ffff88007831ff00] vfs_write at ffffffff8118991c
#12 [ffff88007831ff30] sys_write at ffffffff81189c4a
#13 [ffff88007831ff80] system_call_fastpath at ffffffff815dcae9
RIP: 00007f64d1a94530 RSP: 00007fffbb0c1248 RFLAGS: 00010246
RAX: 0000000000000001 RBX: ffffffff815dcae9 RCX: 00000000fbad2a84
RDX: 0000000000000002 RSI: 00007f64d23ab000 RDI: 0000000000000001
RBP: 00007f64d23ab000 R8: 000000000000000a R9: 00007f64d23a4740
R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000002
R13: 00007f64d1d61280 R14: 0000000000000002 R15: 00007f64d1d61280
ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b
crash>
The "runq -g" output for that cpu looks like this:
CPU 1
CURRENT: PID: 1212 CFS: ffff880035cc2f00 TASK: ffff880035f60000 COMMAND:
"bash"
TASK_GROUP RT_RQ: ffff88007fa541e8
RT PRIO_ARRAY: ffff88007fa541e8
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88007fa540f0
CFS RB_ROOT: ffff88007fa54118
GROUP: ffff880078af7800 CFS_RQ: ffff880035cc2f00 RB_ROOT: ffff880035cc2f28
nr_running: 4294967297 h_nr_running: 201908650262921217
[120] PID: 1212 TASK: ffff880035f60000 COMMAND: "bash"
I don't understand where those values are coming from, because if
I look at the CFS_RQ, it shows this:
crash> cfs_rq.nr_running,h_nr_running ffff880035cc2f00
nr_running = 1
h_nr_running = 1
crash>
I also see this occurring on live "snapshot" dumps -- which I understand given
that the kernel's runqueue data structures are being changed while the dump
is being created. But I don't understand why it's happening in the situation
above.
Dave
----- Original Message -----
----- Original Message -----
> Hi Dave,
>
> I have cleaned up the code and added another change.
OK thanks -- the patch runs through my sample set of vmcores with no problem.
> The current running task is not in the rb tree (rb_root), so run -q
> displays it like:
>
> CURRENT: PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
> TASK_GROUP RT_RQ: ffff880002493820
> RT PRIO_ARRAY: ffff880002493820
> [no tasks queued]
> TASK_GROUP CFS_RQ: ffff8800024936e0
> CFS RB_ROOT: ffff880002493710
> GROUP CFS RB_ROOT: ffff882d609ce830 <TDAT>
> GROUP CFS RB_ROOT: ffff883f0bcbfa30 <User>
> [no tasks queued]
>
> I can understand why the current running task is not displayed.
> However, the "-g" option displays all the task_groups the task
> belongs to but at the end it shows "[no tasks queued]". That is
> just strange. The new change is to display the task that is running like:
>
> CURRENT: PID: 9048 CFS: ffff88039351a800 TASK: ffff8808b07e4200
> COMMAND: "actmain"
> TASK_GROUP RT_RQ: ffff880002493820
> RT PRIO_ARRAY: ffff880002493820
> [no tasks queued]
> TASK_GROUP CFS_RQ: ffff8800024936e0
> CFS RB_ROOT: ffff880002493710
> GROUP: ffff884052bc9800 CFS_RQ: ffff882d609ce800 RB_ROOT:
> ffff882d609ce830 <TDAT> nr_running: 1 h_nr_running: 1
> GROUP: ffff884058f1d000 CFS_RQ: ffff883f0bcbfa00 RB_ROOT:
> ffff883f0bcbfa30 <User> nr_running: 1 h_nr_running: 1
> [120] PID: 9048 TASK: ffff8808b07e4200 COMMAND:
"actmain"
OK -- I guess I understand why it probably makes sense to duplicate the
CURRENT task underneath its own GROUP list -- but if that is done, then
why clutter the CURRENT line with the CFS_RQ address? And it's not clear
to me why in your example above, the CFS address of ffff88039351a800
doesn't show up as the CFS_RQ address above the "actmain" line?
Taking a simple example, I see this:
crash> runq -g
CPU 0
CURRENT: PID: 0 CFS: ffff88000c7d6aa8 TASK: ffffffff8178ba60 COMMAND:
"swapper"
TASK_GROUP RT_RQ: ffff88000c7d6b58
RT PRIO_ARRAY: ffff88000c7d6b58
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88000c7d6aa8
CFS RB_ROOT: ffff88000c7d6ad0
[no tasks queued]
CPU 1
CURRENT: PID: 1268 CFS: ffff88000c9b5aa8 TASK: ffff88002f11c620 COMMAND:
"bash"
TASK_GROUP RT_RQ: ffff88000c9b5b58
RT PRIO_ARRAY: ffff88000c9b5b58
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88000c9b5aa8
CFS RB_ROOT: ffff88000c9b5ad0
[120] PID: 1268 TASK: ffff88002f11c620 COMMAND: "bash"
crash>
Where the newly-interspersed CFS address redundantly shows the TASK_GROUP
CFS_RQ
below. But adding the CFS address to the "swapper" line doesn't seem to
make
much sense, or help in any way, since the idle task is a special case that
never
gets queued. And since the CFS address in the "bash" line is redundant with
the
TASK_GROUP CFS_RQ below, why bother showing it?
And in a more complicated example, with your patch, the "qemu-kvm" task also
shows up underneath its group:
CPU 0
CURRENT: PID: 3144 CFS: ffff88022aab2600 TASK: ffff88022a446040 COMMAND:
"qemu-kvm"
TASK_GROUP RT_RQ: ffff880133c16148
RT PRIO_ARRAY: ffff880133c16148
[no tasks queued]
TASK_GROUP CFS_RQ: ffff880133c16028
CFS RB_ROOT: ffff880133c16058
GROUP: ffff88012b880800 CFS_RQ: ffff88022ac8f000 RB_ROOT:
ffff88022ac8f030 <libvirt> nr_running: 1 h_nr_running: 1
GROUP: ffff88012c078000 CFS_RQ: ffff88022c075000 RB_ROOT:
ffff88022c075030 <qemu> nr_running: 1 h_nr_running: 1
GROUP: ffff88012b0fb400 CFS_RQ: ffff88022af94c00 RB_ROOT:
ffff88022af94c30 <guest1> nr_running: 1 h_nr_running: 1
GROUP: ffff88022c6bbc00 CFS_RQ: ffff88022aab2600 RB_ROOT:
ffff88022aab2630 <vcpu1> nr_running: 1 h_nr_running: 1
[120] PID: 3144 TASK: ffff88022a446040 COMMAND:
"qemu-kvm"
And note that its interspersed CFS address of ffff88022aab2600 is redundantly
shown
as the CFS_RQ of its GROUP down below.
So I don't understand why your example shows different CFS addresses in the
CURRENT line vs. the GROUP CFS_RQ address above the queued "acctmain" task:
> CURRENT: PID: 9048 CFS: ffff88039351a800 TASK: ffff8808b07e4200
> COMMAND: "actmain"
> TASK_GROUP RT_RQ: ffff880002493820
> RT PRIO_ARRAY: ffff880002493820
> [no tasks queued]
> TASK_GROUP CFS_RQ: ffff8800024936e0
> CFS RB_ROOT: ffff880002493710
> GROUP: ffff884052bc9800 CFS_RQ: ffff882d609ce800 RB_ROOT:
> ffff882d609ce830 <TDAT> nr_running: 1 h_nr_running: 1
> GROUP: ffff884058f1d000 CFS_RQ: ffff883f0bcbfa00 RB_ROOT:
> ffff883f0bcbfa30 <User> nr_running: 1 h_nr_running: 1
> [120] PID: 9048 TASK: ffff8808b07e4200 COMMAND:
"actmain"
Am I missing something? Or is there cut-and-paste error?
Dave
7:58 a.m.
New subject: patch for slight modification to runq -g command
----- Original Message -----
The "runq -g" output for that cpu looks like this:
CPU 1
CURRENT: PID: 1212 CFS: ffff880035cc2f00 TASK: ffff880035f60000
COMMAND: "bash"
TASK_GROUP RT_RQ: ffff88007fa541e8
RT PRIO_ARRAY: ffff88007fa541e8
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88007fa540f0
CFS RB_ROOT: ffff88007fa54118
GROUP: ffff880078af7800 CFS_RQ: ffff880035cc2f00 RB_ROOT: ffff880035cc2f28
nr_running: 4294967297 h_nr_running: 201908650262921217
[120] PID: 1212 TASK: ffff880035f60000 COMMAND: "bash"
I don't understand where those values are coming from, because if
I look at the CFS_RQ, it shows this:
crash> cfs_rq.nr_running,h_nr_running ffff880035cc2f00
nr_running = 1
h_nr_running = 1
crash>
The problem above is due to the fact that both nr_running and h_nr_running
are of type unsigned int but your patch reads each of them as a ulong:
crash> eval 4294967297
hexadecimal: 100000001
decimal: 4294967297
octal: 40000000001
binary: 0000000000000000000000000000000100000000000000000000000000000001
crash> eval 201908650262921217
hexadecimal: 2cd52d900000001
decimal: 201908650262921217
octal: 13152455440000000001
binary: 0000001011001101010100101101100100000000000000000000000000000001
crash>
+ readmem(cfs_rq + OFFSET(cfs_rq_nr_running), KVADDR,
+ &nr_running, sizeof(ulong), "cfs_rq nr_running",
+ FAULT_ON_ERROR);
+ if (VALID_MEMBER(cfs_rq_h_nr_running)) {
+ readmem(cfs_rq + OFFSET(cfs_rq_h_nr_running), KVADDR,
+ &h_nr_running, sizeof(ulong), "cfs_rq
h_nr_running",
+ FAULT_ON_ERROR);
+ fprintf(fp, " nr_running: %lu h_nr_running: %lu ", nr_running,
h_nr_running);
+ } else {
+ fprintf(fp, " nr_running: %lu ", nr_running);
+ }
But again, I don't seen any compelling reason to display them at all -- especially
now that your patch displays the cfs_rq from which they come. If you really
need to see their values, just dump the data structure.
And as I mentioned earlier, the CFS address in the CURRENT: line is confusing and
redundant. Perhaps you could clarify things by appending "[CURRENT]" after
the task identifier in the queue, i.e., like:
[120] PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain" [CURRENT]
Thanks,
Dave
12:12 p.m.
New subject: patch for slight modification to runq -g command
I had hesitated about putting in the nr_running and h_nr_running values. I'll remove
those and add the "[CURRENT]" label.
Thanks,
Anthony
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
bounces(a)redhat.com] On Behalf Of Dave Anderson
Sent: Friday, November 08, 2013 5:58 AM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] patch for slight modification to runq -g
command
----- Original Message -----
>
> The "runq -g" output for that cpu looks like this:
>
> CPU 1
> CURRENT: PID: 1212 CFS: ffff880035cc2f00 TASK: ffff880035f60000
> COMMAND: "bash"
> TASK_GROUP RT_RQ: ffff88007fa541e8
> RT PRIO_ARRAY: ffff88007fa541e8
> [no tasks queued]
> TASK_GROUP CFS_RQ: ffff88007fa540f0
> CFS RB_ROOT: ffff88007fa54118
> GROUP: ffff880078af7800 CFS_RQ: ffff880035cc2f00 RB_ROOT:
ffff880035cc2f28 nr_running: 4294967297 h_nr_running:
201908650262921217
> [120] PID: 1212 TASK: ffff880035f60000 COMMAND: "bash"
>
> I don't understand where those values are coming from, because if
> I look at the CFS_RQ, it shows this:
>
> crash> cfs_rq.nr_running,h_nr_running ffff880035cc2f00
> nr_running = 1
> h_nr_running = 1
> crash>
The problem above is due to the fact that both nr_running and
h_nr_running
are of type unsigned int but your patch reads each of them as a ulong:
crash> eval 4294967297
hexadecimal: 100000001
decimal: 4294967297
octal: 40000000001
binary:
000000000000000000000000000000010000000000000000000000000000000
1
crash> eval 201908650262921217
hexadecimal: 2cd52d900000001
decimal: 201908650262921217
octal: 13152455440000000001
binary:
000000101100110101010010110110010000000000000000000000000000000
1
crash>
+ readmem(cfs_rq + OFFSET(cfs_rq_nr_running), KVADDR,
+ &nr_running, sizeof(ulong), "cfs_rq nr_running",
+ FAULT_ON_ERROR);
+ if (VALID_MEMBER(cfs_rq_h_nr_running)) {
+ readmem(cfs_rq + OFFSET(cfs_rq_h_nr_running), KVADDR,
+ &h_nr_running, sizeof(ulong), "cfs_rq
h_nr_running",
+ FAULT_ON_ERROR);
+ fprintf(fp, " nr_running: %lu h_nr_running: %lu ", nr_running,
h_nr_running);
+ } else {
+ fprintf(fp, " nr_running: %lu ", nr_running);
+ }
But again, I don't seen any compelling reason to display them at all --
especially
now that your patch displays the cfs_rq from which they come. If you
really
need to see their values, just dump the data structure.
And as I mentioned earlier, the CFS address in the CURRENT: line is
confusing and
redundant. Perhaps you could clarify things by appending "[CURRENT]"
after
the task identifier in the queue, i.e., like:
[120] PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
[CURRENT]
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
12:39 p.m.
New subject: patch for slight modification to runq -g command
Dave,
I have removed the nr_running and h_nr_running related code and added
"[CURRENT]" at the end of the current running task line.
Thanks,
Anthony
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
bounces(a)redhat.com] On Behalf Of Dave Anderson
Sent: Friday, November 08, 2013 5:58 AM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] patch for slight modification to runq -g
command
----- Original Message -----
>
> The "runq -g" output for that cpu looks like this:
>
> CPU 1
> CURRENT: PID: 1212 CFS: ffff880035cc2f00 TASK: ffff880035f60000
> COMMAND: "bash"
> TASK_GROUP RT_RQ: ffff88007fa541e8
> RT PRIO_ARRAY: ffff88007fa541e8
> [no tasks queued]
> TASK_GROUP CFS_RQ: ffff88007fa540f0
> CFS RB_ROOT: ffff88007fa54118
> GROUP: ffff880078af7800 CFS_RQ: ffff880035cc2f00 RB_ROOT:
ffff880035cc2f28 nr_running: 4294967297 h_nr_running:
201908650262921217
> [120] PID: 1212 TASK: ffff880035f60000 COMMAND: "bash"
>
> I don't understand where those values are coming from, because if
> I look at the CFS_RQ, it shows this:
>
> crash> cfs_rq.nr_running,h_nr_running ffff880035cc2f00
> nr_running = 1
> h_nr_running = 1
> crash>
The problem above is due to the fact that both nr_running and
h_nr_running
are of type unsigned int but your patch reads each of them as a ulong:
crash> eval 4294967297
hexadecimal: 100000001
decimal: 4294967297
octal: 40000000001
binary:
000000000000000000000000000000010000000000000000000000000000000
1
crash> eval 201908650262921217
hexadecimal: 2cd52d900000001
decimal: 201908650262921217
octal: 13152455440000000001
binary:
000000101100110101010010110110010000000000000000000000000000000
1
crash>
+ readmem(cfs_rq + OFFSET(cfs_rq_nr_running), KVADDR,
+ &nr_running, sizeof(ulong), "cfs_rq nr_running",
+ FAULT_ON_ERROR);
+ if (VALID_MEMBER(cfs_rq_h_nr_running)) {
+ readmem(cfs_rq + OFFSET(cfs_rq_h_nr_running), KVADDR,
+ &h_nr_running, sizeof(ulong), "cfs_rq
h_nr_running",
+ FAULT_ON_ERROR);
+ fprintf(fp, " nr_running: %lu h_nr_running: %lu ", nr_running,
h_nr_running);
+ } else {
+ fprintf(fp, " nr_running: %lu ", nr_running);
+ }
But again, I don't seen any compelling reason to display them at all --
especially
now that your patch displays the cfs_rq from which they come. If you
really
need to see their values, just dump the data structure.
And as I mentioned earlier, the CFS address in the CURRENT: line is
confusing and
redundant. Perhaps you could clarify things by appending "[CURRENT]"
after
the task identifier in the queue, i.e., like:
[120] PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
[CURRENT]
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
3:28 p.m.
New subject: patch for slight modification to runq -g command
----- Original Message -----
Dave,
I have removed the nr_running and h_nr_running related code and added
"[CURRENT]" at the end of the current running task line.
Thanks,
Anthony
Anthony,
As I requested before, can you also please remove the "CFS: <address>"
addition from the CURRENT: line? It makes little sense w/respect to the
swapper tasks, and it is redundant w/respect to the other tasks since
the "[CURRENT]" identifier has been added:
crash> runq -g
CPU 0
CURRENT: PID: 0 CFS: ffff88021e2140b0 TASK: ffffffff81c13440 COMMAND:
"swapper/0"
TASK_GROUP RT_RQ: ffff88021e2141c0
RT PRIO_ARRAY: ffff88021e2141c0
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88021e2140b0
CFS RB_ROOT: ffff88021e2140d8
[no tasks queued]
CPU 1
CURRENT: PID: 11532 CFS: ffff8801f6e00a00 TASK: ffff8800a0e9e9e0 COMMAND:
"crash"
TASK_GROUP RT_RQ: ffff88021e2541c0
RT PRIO_ARRAY: ffff88021e2541c0
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88021e2540b0
CFS RB_ROOT: ffff88021e2540d8
GROUP: ffff8800a0e92c00 CFS_RQ: ffff8801f6e00a00 RB_ROOT: ffff8801f6e00a28
[120] PID: 11532 TASK: ffff8800a0e9e9e0 COMMAND: "crash" [CURRENT]
...
Thanks,
Dave
> -----Original Message-----
> From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
> bounces(a)redhat.com] On Behalf Of Dave Anderson
> Sent: Friday, November 08, 2013 5:58 AM
> To: Discussion list for crash utility usage, maintenance and
> development
> Subject: Re: [Crash-utility] patch for slight modification to runq -g
> command
>
>
>
> ----- Original Message -----
> >
> > The "runq -g" output for that cpu looks like this:
> >
> > CPU 1
> > CURRENT: PID: 1212 CFS: ffff880035cc2f00 TASK: ffff880035f60000
> > COMMAND: "bash"
> > TASK_GROUP RT_RQ: ffff88007fa541e8
> > RT PRIO_ARRAY: ffff88007fa541e8
> > [no tasks queued]
> > TASK_GROUP CFS_RQ: ffff88007fa540f0
> > CFS RB_ROOT: ffff88007fa54118
> > GROUP: ffff880078af7800 CFS_RQ: ffff880035cc2f00 RB_ROOT:
> ffff880035cc2f28 nr_running: 4294967297 h_nr_running:
> 201908650262921217
> > [120] PID: 1212 TASK: ffff880035f60000 COMMAND:
"bash"
> >
> > I don't understand where those values are coming from, because if
> > I look at the CFS_RQ, it shows this:
> >
> > crash> cfs_rq.nr_running,h_nr_running ffff880035cc2f00
> > nr_running = 1
> > h_nr_running = 1
> > crash>
>
> The problem above is due to the fact that both nr_running and
> h_nr_running
> are of type unsigned int but your patch reads each of them as a ulong:
>
> crash> eval 4294967297
> hexadecimal: 100000001
> decimal: 4294967297
> octal: 40000000001
> binary:
> 000000000000000000000000000000010000000000000000000000000000000
> 1
> crash> eval 201908650262921217
> hexadecimal: 2cd52d900000001
> decimal: 201908650262921217
> octal: 13152455440000000001
> binary:
> 000000101100110101010010110110010000000000000000000000000000000
> 1
> crash>
>
> + readmem(cfs_rq + OFFSET(cfs_rq_nr_running), KVADDR,
> + &nr_running, sizeof(ulong), "cfs_rq nr_running",
> + FAULT_ON_ERROR);
> + if (VALID_MEMBER(cfs_rq_h_nr_running)) {
> + readmem(cfs_rq + OFFSET(cfs_rq_h_nr_running), KVADDR,
> + &h_nr_running, sizeof(ulong), "cfs_rq
> h_nr_running",
> + FAULT_ON_ERROR);
> + fprintf(fp, " nr_running: %lu h_nr_running: %lu ",
> nr_running,
> h_nr_running);
> + } else {
> + fprintf(fp, " nr_running: %lu ", nr_running);
> + }
>
> But again, I don't seen any compelling reason to display them at all --
> especially
> now that your patch displays the cfs_rq from which they come. If you
> really
> need to see their values, just dump the data structure.
>
> And as I mentioned earlier, the CFS address in the CURRENT: line is
> confusing and
> redundant. Perhaps you could clarify things by appending "[CURRENT]"
> after
> the task identifier in the queue, i.e., like:
>
> [120] PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
> [CURRENT]
>
> Thanks,
> Dave
>
>
>
>
>
>
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
4:22 p.m.
New subject: patch for slight modification to runq -g command
My mistake, I didn't read your email carefully enough. Here's the new patch.
Thanks,
Anthony
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
bounces(a)redhat.com] On Behalf Of Dave Anderson
Sent: Friday, November 08, 2013 1:29 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] patch for slight modification to runq -g
command
----- Original Message -----
> Dave,
>
> I have removed the nr_running and h_nr_running related code and
added
> "[CURRENT]" at the end of the current running task line.
>
> Thanks,
> Anthony
Anthony,
As I requested before, can you also please remove the "CFS: <address>"
addition from the CURRENT: line? It makes little sense w/respect to the
swapper tasks, and it is redundant w/respect to the other tasks since
the "[CURRENT]" identifier has been added:
crash> runq -g
CPU 0
CURRENT: PID: 0 CFS: ffff88021e2140b0 TASK: ffffffff81c13440
COMMAND: "swapper/0"
TASK_GROUP RT_RQ: ffff88021e2141c0
RT PRIO_ARRAY: ffff88021e2141c0
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88021e2140b0
CFS RB_ROOT: ffff88021e2140d8
[no tasks queued]
CPU 1
CURRENT: PID: 11532 CFS: ffff8801f6e00a00 TASK: ffff8800a0e9e9e0
COMMAND: "crash"
TASK_GROUP RT_RQ: ffff88021e2541c0
RT PRIO_ARRAY: ffff88021e2541c0
[no tasks queued]
TASK_GROUP CFS_RQ: ffff88021e2540b0
CFS RB_ROOT: ffff88021e2540d8
GROUP: ffff8800a0e92c00 CFS_RQ: ffff8801f6e00a00 RB_ROOT:
ffff8801f6e00a28
[120] PID: 11532 TASK: ffff8800a0e9e9e0 COMMAND: "crash"
[CURRENT]
...
Thanks,
Dave
>
> > -----Original Message-----
> > From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
> > bounces(a)redhat.com] On Behalf Of Dave Anderson
> > Sent: Friday, November 08, 2013 5:58 AM
> > To: Discussion list for crash utility usage, maintenance and
> > development
> > Subject: Re: [Crash-utility] patch for slight modification to runq -g
> > command
> >
> >
> >
> > ----- Original Message -----
> > >
> > > The "runq -g" output for that cpu looks like this:
> > >
> > > CPU 1
> > > CURRENT: PID: 1212 CFS: ffff880035cc2f00 TASK:
ffff880035f60000
> > > COMMAND: "bash"
> > > TASK_GROUP RT_RQ: ffff88007fa541e8
> > > RT PRIO_ARRAY: ffff88007fa541e8
> > > [no tasks queued]
> > > TASK_GROUP CFS_RQ: ffff88007fa540f0
> > > CFS RB_ROOT: ffff88007fa54118
> > > GROUP: ffff880078af7800 CFS_RQ: ffff880035cc2f00 RB_ROOT:
> > ffff880035cc2f28 nr_running: 4294967297 h_nr_running:
> > 201908650262921217
> > > [120] PID: 1212 TASK: ffff880035f60000 COMMAND:
"bash"
> > >
> > > I don't understand where those values are coming from, because
if
> > > I look at the CFS_RQ, it shows this:
> > >
> > > crash> cfs_rq.nr_running,h_nr_running ffff880035cc2f00
> > > nr_running = 1
> > > h_nr_running = 1
> > > crash>
> >
> > The problem above is due to the fact that both nr_running and
> > h_nr_running
> > are of type unsigned int but your patch reads each of them as a
ulong:
> >
> > crash> eval 4294967297
> > hexadecimal: 100000001
> > decimal: 4294967297
> > octal: 40000000001
> > binary:
> >
000000000000000000000000000000010000000000000000000000000000000
> > 1
> > crash> eval 201908650262921217
> > hexadecimal: 2cd52d900000001
> > decimal: 201908650262921217
> > octal: 13152455440000000001
> > binary:
> >
000000101100110101010010110110010000000000000000000000000000000
> > 1
> > crash>
> >
> > + readmem(cfs_rq + OFFSET(cfs_rq_nr_running), KVADDR,
> > + &nr_running, sizeof(ulong), "cfs_rq
nr_running",
> > + FAULT_ON_ERROR);
> > + if (VALID_MEMBER(cfs_rq_h_nr_running)) {
> > + readmem(cfs_rq + OFFSET(cfs_rq_h_nr_running),
KVADDR,
> > + &h_nr_running, sizeof(ulong), "cfs_rq
> > h_nr_running",
> > + FAULT_ON_ERROR);
> > + fprintf(fp, " nr_running: %lu h_nr_running: %lu
",
> > nr_running,
> > h_nr_running);
> > + } else {
> > + fprintf(fp, " nr_running: %lu ", nr_running);
> > + }
> >
> > But again, I don't seen any compelling reason to display them at all -
-
> > especially
> > now that your patch displays the cfs_rq from which they come. If
you
> > really
> > need to see their values, just dump the data structure.
> >
> > And as I mentioned earlier, the CFS address in the CURRENT: line is
> > confusing and
> > redundant. Perhaps you could clarify things by appending
"[CURRENT]"
> > after
> > the task identifier in the queue, i.e., like:
> >
> > [120] PID: 9048 TASK: ffff8808b07e4200 COMMAND: "actmain"
> > [CURRENT]
> >
> > Thanks,
> > Dave
> >
> >
> >
> >
> >
> >
> >
> > --
> > Crash-utility mailing list
> > Crash-utility(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
1:58 p.m.
New subject: patch for slight modification to runq -g command
----- Original Message -----
My mistake, I didn't read your email carefully enough. Here's
the new patch.
Thanks,
Anthony
Thanks Anthony -- your changes are queued for crash-7.0.4.
Dave
> -----Original Message-----
> From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
> bounces(a)redhat.com] On Behalf Of Dave Anderson
> Sent: Friday, November 08, 2013 1:29 PM
> To: Discussion list for crash utility usage, maintenance and
> development
> Subject: Re: [Crash-utility] patch for slight modification to runq -g
> command
>
>
>
> ----- Original Message -----
> > Dave,
> >
> > I have removed the nr_running and h_nr_running related code and
> added
> > "[CURRENT]" at the end of the current running task line.
> >
> > Thanks,
> > Anthony
>
>
> Anthony,
>
> As I requested before, can you also please remove the "CFS:
<address>"
> addition from the CURRENT: line? It makes little sense w/respect to
> the
> swapper tasks, and it is redundant w/respect to the other tasks since
> the "[CURRENT]" identifier has been added:
>
> crash> runq -g
> CPU 0
> CURRENT: PID: 0 CFS: ffff88021e2140b0 TASK: ffffffff81c13440
> COMMAND: "swapper/0"
> TASK_GROUP RT_RQ: ffff88021e2141c0
> RT PRIO_ARRAY: ffff88021e2141c0
> [no tasks queued]
> TASK_GROUP CFS_RQ: ffff88021e2140b0
> CFS RB_ROOT: ffff88021e2140d8
> [no tasks queued]
>
> CPU 1
> CURRENT: PID: 11532 CFS: ffff8801f6e00a00 TASK: ffff8800a0e9e9e0
> COMMAND: "crash"
> TASK_GROUP RT_RQ: ffff88021e2541c0
> RT PRIO_ARRAY: ffff88021e2541c0
> [no tasks queued]
> TASK_GROUP CFS_RQ: ffff88021e2540b0
> CFS RB_ROOT: ffff88021e2540d8
> GROUP: ffff8800a0e92c00 CFS_RQ: ffff8801f6e00a00 RB_ROOT:
> ffff8801f6e00a28
> [120] PID: 11532 TASK: ffff8800a0e9e9e0 COMMAND: "crash"
> [CURRENT]
> ...
>
> Thanks,
> Dave
>
>
>
> >
> > > -----Original Message-----
> > > From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
> > > bounces(a)redhat.com] On Behalf Of Dave Anderson
> > > Sent: Friday, November 08, 2013 5:58 AM
> > > To: Discussion list for crash utility usage, maintenance and
> > > development
> > > Subject: Re: [Crash-utility] patch for slight modification to
> > > runq -g
> > > command
> > >
> > >
> > >
> > > ----- Original Message -----
> > > >
> > > > The "runq -g" output for that cpu looks like this:
> > > >
> > > > CPU 1
> > > > CURRENT: PID: 1212 CFS: ffff880035cc2f00 TASK:
> ffff880035f60000
> > > > COMMAND: "bash"
> > > > TASK_GROUP RT_RQ: ffff88007fa541e8
> > > > RT PRIO_ARRAY: ffff88007fa541e8
> > > > [no tasks queued]
> > > > TASK_GROUP CFS_RQ: ffff88007fa540f0
> > > > CFS RB_ROOT: ffff88007fa54118
> > > > GROUP: ffff880078af7800 CFS_RQ: ffff880035cc2f00
> > > > RB_ROOT:
> > > ffff880035cc2f28 nr_running: 4294967297 h_nr_running:
> > > 201908650262921217
> > > > [120] PID: 1212 TASK: ffff880035f60000 COMMAND:
> > > > "bash"
> > > >
> > > > I don't understand where those values are coming from,
> > > > because
> if
> > > > I look at the CFS_RQ, it shows this:
> > > >
> > > > crash> cfs_rq.nr_running,h_nr_running ffff880035cc2f00
> > > > nr_running = 1
> > > > h_nr_running = 1
> > > > crash>
> > >
> > > The problem above is due to the fact that both nr_running and
> > > h_nr_running
> > > are of type unsigned int but your patch reads each of them as a
> ulong:
> > >
> > > crash> eval 4294967297
> > > hexadecimal: 100000001
> > > decimal: 4294967297
> > > octal: 40000000001
> > > binary:
> > >
> 000000000000000000000000000000010000000000000000000000000000000
> > > 1
> > > crash> eval 201908650262921217
> > > hexadecimal: 2cd52d900000001
> > > decimal: 201908650262921217
> > > octal: 13152455440000000001
> > > binary:
> > >
> 000000101100110101010010110110010000000000000000000000000000000
> > > 1
> > > crash>
> > >
> > > + readmem(cfs_rq + OFFSET(cfs_rq_nr_running), KVADDR,
> > > + &nr_running, sizeof(ulong), "cfs_rq
> > > nr_running",
> > > + FAULT_ON_ERROR);
> > > + if (VALID_MEMBER(cfs_rq_h_nr_running)) {
> > > + readmem(cfs_rq + OFFSET(cfs_rq_h_nr_running),
> KVADDR,
> > > + &h_nr_running, sizeof(ulong),
"cfs_rq
> > > h_nr_running",
> > > + FAULT_ON_ERROR);
> > > + fprintf(fp, " nr_running: %lu h_nr_running:
%lu
> > > ",
> > > nr_running,
> > > h_nr_running);
> > > + } else {
> > > + fprintf(fp, " nr_running: %lu ",
nr_running);
> > > + }
> > >
> > > But again, I don't seen any compelling reason to display them
> > > at all -
> -
> > > especially
> > > now that your patch displays the cfs_rq from which they come.
> > > If
> you
> > > really
> > > need to see their values, just dump the data structure.
> > >
> > > And as I mentioned earlier, the CFS address in the CURRENT:
> > > line is
> > > confusing and
> > > redundant. Perhaps you could clarify things by appending
> "[CURRENT]"
> > > after
> > > the task identifier in the queue, i.e., like:
> > >
> > > [120] PID: 9048 TASK: ffff8808b07e4200 COMMAND:
> > > "actmain"
> > > [CURRENT]
> > >
> > > Thanks,
> > > Dave
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Crash-utility mailing list
> > > Crash-utility(a)redhat.com
> > > https://www.redhat.com/mailman/listinfo/crash-utility
> >
> > --
> > Crash-utility mailing list
> > Crash-utility(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
3:50 p.m.
New subject: patch for slight modification to runq -g command
----- Original Message -----
----- Original Message -----
> My mistake, I didn't read your email carefully enough. Here's the new
> patch.
>
> Thanks,
> Anthony
Thanks Anthony -- your changes are queued for crash-7.0.4.
Dave
Anthony,
Given your interest in this command, I have a question re: the display.
Do you ever have any interest in the rb_root addresses in each group?
I'm thinking that with your patch adding the task_group and cfs_rq
addresses, that the rb_root address is fairly useless. It was
pretty much carried forward from the base "runq" command display,
where it makes some sense.
Dave
4031
days inactive
4059
days old
devel@lists.crash-utility.osci.io
13 comments
2 participants
participants (2)
-
Chen, Anthony -
Dave Anderson