于 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