[Crash-utility] [PATCH] Add -m option to kmem
Zhang Yanfei
zhangyanfei at cn.fujitsu.com
Tue Mar 19 06:57:39 UTC 2013
于 2013年03月07日 04:27, Dave Anderson 写道:
>
>
> ----- 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.
Hello Dave,
Sorry for the delay.
>
> 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?
>From output of kmem -p. Mapping with the following bits set are
addresses of stable_node objects.
#define PAGE_MAPPING_ANON 1
#define PAGE_MAPPING_KSM 2
See the comment below:
include/linux/mm.h:
/*
* On an anonymous page mapped into a user virtual memory area,
* page->mapping points to its anon_vma, not to a struct address_space;
* with the PAGE_MAPPING_ANON bit set to distinguish it. See rmap.h.
*
* On an anonymous page in a VM_MERGEABLE area, if CONFIG_KSM is enabled,
* the PAGE_MAPPING_KSM bit may be set along with the PAGE_MAPPING_ANON bit;
* and then page->mapping points, not to an anon_vma, but to a private
* structure which KSM associates with that merged page. See ksm.h.
*
* PAGE_MAPPING_KSM without PAGE_MAPPING_ANON is currently never used.
*
* Please note that, confusingly, "page_mapping" refers to the inode
* address_space which maps the page from disk; whereas "page_mapped"
* refers to user virtual address space into which the page is mapped.
*/
#define PAGE_MAPPING_ANON 1
#define PAGE_MAPPING_KSM 2
#define PAGE_MAPPING_FLAGS (PAGE_MAPPING_ANON | PAGE_MAPPING_KSM)
>
>>>
>>> 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,
Yes, this is 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>
> ...
After discussing this with other members, we have the new output below:
crash> kmem -m <stable_node object>
STABLE_NODE: <stable_node address> PHYSICAL ADDRESS: <address>
PID: 15864 MAPPING: 8713
VIRTUAL:
3639c1d000
3639c1e000
3639c1f000
...
PID: 16781 MAPPING: 34
VIRTUAL:
41f000
42f000
51f000
...
In this output, we also display the virtual addresses that mapping the physical
address.
And kmem -m without arguments will display all the ksm pages. Like below:
crash> kmem -m
STABLE_NODE: <stable_node address> PHYSICAL ADDRESS: <address>
PID: 15864 MAPPING: 8713
VIRTUAL:
3639c1d000
3639c1e000
3639c1f000
...
PID: 16781 MAPPING: 34
VIRTUAL:
41f000
42f000
51f000
...
STABLE_NODE: <stable_node address> PHYSICAL ADDRESS: <address>
PID: 15866 MAPPING: 871
VIRTUAL:
3739c1d000
3739c1e000
3739c1f000
...
PID: 16786 MAPPING: 342
VIRTUAL:
43f000
44f000
53f000
...
......
Thanks
Zhang
>
> 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
>
>
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
More information about the Crash-utility
mailing list