Re: [PATCH] Add -m option to kmem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



于 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

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility





[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux