[Crash-utility] [PATCH] Add -m option to kmem

Dave Anderson anderson at redhat.com
Wed Mar 6 20:27:52 UTC 2013



----- Original Message -----
> >>>
> >>> But a couple quick questions...
> >>>
> >>> What does "kmem -m" alone look like?  Your help page example only
> >>> shows the command passing a "ksm stable tree node address".
> >>
> >> 'kmem -m' will display all the ksm pages.
> > 
> > I meant could you show an example of "kmem -m"...
> > 
> >>
> >>> How would a user know what one of those addresses would be?
> >>
> >> From the structure "rmap_item" ? it has a member "head" that points
> >> to a ksm stable tree node.

OK, but how would a crash user know how to find such an address?

I'm just trying to imagine a situation where someone would
bring up a crash session on a vmcore, and somehow "know" in
advance what one of these embedded stable_node addresses 
would be?
 
> > 
> > So does "kmem -m" show a list of those addresses?
> 
> oops...I misunderstood your question. The display is like:
> 
> crash> kmem -m
>              PID:  3622  3512
>        867605000:   187  7671
> 
>              PID:  3622  3512
>        465837000:     1     1
> 
>              PID:  3622  3512
>        465803000:     1     1
> 
>              PID:  3512
>        4643d0000:     2
> 
>              PID:  3512
>        81bddc000:     2
> 
>              PID:  3512
>        841c36000:     2
> 
>              PID:  3512
>        4653e5000:     2
> 
>              PID:  3512
>        842bc1000:     3
> 
>              PID:  3512
>        455b4b000:    11
> 
>              PID:  3512
>        453842000:     3
> ......
> 
> All ksm pages are displayed. For every ksm page, for example
> a ksm page with physical address 867605000, has two tasks
> reference it: 3622 and 3512. 3622 has 187 virtual mappings
> into the ksm page and 3512 has 7671 virtual mappings into
> the ksm page.
> 
>              PID:  3622  3512
>        867605000:   187  7671

Now, for every one of these physical addresses, is there
a single associated stable_node structure?  If that's true,
then the concept of the "kmem -m <stable_node>" might make
sense in order to scale down the output of the "kmem -m" alone.
But you would have to display the stable_node address along
with the physical address.
  
> 
> > 
> >>>
> >>> And for "kmem -m <address>", what if there are dozens of PIDs
> >>> that
> >>> are mapping the same physical address?  Regardless of the size of
> >>> the display window, eventually it would get messy if it extends
> >>> to
> >>> more than one line.  I try to avoid having commands extend beyond
> >>> 80 columns if at all possible.
> >>>
> >>
> >> Hmm. If there are quite many PIDs, can the output be like below?
> >>
> >>              PID: 15864 16781 16782 16783
> >>        793005000:  8713  5584    23    23
> >>                   12222 13333 14444 15555
> >>                     232   232   334   456
> >>                   ...
> > 
> > Well, that's not much clearer -- it's difficult to tell whether the
> > numbers are PIDs or counts.
> 
> Do you have any suggestions...

I'm not sure -- this is such an obscure command request that it's hard
to understand a scenario where anybody would use it.  But I'm sure you
have your reasons.

But maybe something like this (with size of 80 columns shown for a reference):

12345678901234567890123456789012345678901234567890123456789012345678901234567890

 crash> kmem -m

 STABLE_NODE: <address>  PHYSICAL ADDRESS: <address>

         PID: 15864  16781  16782  16783  12222  13333  14444  15555
    MAPPINGS:  8713   5584     23     23    232    232    334    456
         PID: 13864  16882  16782  16783  15890  13789  16876  14800
    MAPPINGS:  2471   7583   1119    541    232   3455    532    210
         PID: 15789  13434 
    MAPPINGS:   667   2424

 STABLE_NODE: <address>  PHYSICAL ADDRESS: <address>

         PID:  1345  12367
    MAPPINGS:    14    400

 STABLE_NODE: <address>  PHYSICAL ADDRESS: <address>
   ...

For that matter, it almost makes more sense if the alternative command
were to be "kmem -m <physical-address>", and the stable_node address
would not have to be displayed above.  It looks like the only thing useful
in the stable_node structure is the "kpfn" value, which is the pfn of the
physical address shown above, correct?  

I just can't see using the stable_node address as a "handle" in this
command.  Yes, you obviously need it behind the scenes in order to
display the data -- but what good is it to the crash utility user?

Dave

  




More information about the Crash-utility mailing list