[Crash-utility] [PATCH] Add -m option to kmem
Zhang Yanfei
zhangyanfei at cn.fujitsu.com
Mon Mar 25 01:53:17 UTC 2013
于 2013年03月19日 22:52, Dave Anderson 写道:
>
>
> ----- Original Message -----
>> 于 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
>
> Well that adds a new angle, where the page structure address seems to
> also be a logical "handle" -- in addition to the physical address
> and stable_node address. I would think that you would also want
> to display the page-struct address as well.
>
> I still don't understand why you want to restrict the optional
> argument to a stable_node address, especially given that the page->mapping
> "address" seen in "kmem -p" will have that extra 2-bit encoded into it,
> so the user would have to remember to manually delete it when cutting-and-pasting
> it from the "kmem -p" output.
>
> Why not do what many of the other "kmem" options do, and allow the optional
> argument to be either a page-struct address, a virtual address (of a
> stable_node in this case), or a physical address? Also you might want
> to allow the user to enter the stable_node address directly from the
> "kmem -p" output, and have the command strip the 2-bit off if the user
> left it there. (I think we do that kind of thing somewhere else...)
>
So the commandline may be:
crash > kmem -m [stable_node_addr | page_struct_addr | physical_addr]
the output may be:
>>
>> STABLE_NODE : <stable_node address>
>> PAGE : <page pointer 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>
>> PAGE : <page pointer address>
>> PHYSICAL ADDRESS: <address>
>>
>> PID: 15866 MAPPING: 871
>> VIRTUAL:
>> 3739c1d000
>> 3739c1e000
>> 3739c1f000
>> ...
>> PID: 16786 MAPPING: 342
>> VIRTUAL:
>> 43f000
>> 44f000
>> 53f000
>> ...
Is this ok for you?
Thanks
Zhang
More information about the Crash-utility
mailing list