[Crash-utility] patch for slight modification to runq -g command

[Chen, Anthony]

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 at redhat.com [mailto:crash-utility-
    > bounces at 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 at redhat.com
    > https://www.redhat.com/mailman/listinfo/crash-utility
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash_runq_g_3.patch
Type: application/octet-stream
Size: 8401 bytes
Desc: crash_runq_g_3.patch
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20131108/152debb0/attachment.obj>