[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