Re: [Crash-utility] [PATCH] Add -m option to kmem

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

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