Re: [PATCH] Add -m option to kmem

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

 




----- 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...)

Dave

--
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