于 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
