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

于 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