----- 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. 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? > > > > 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, 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> ... For that matter, it almost makes more sense if the alternative command were to be "kmem -m <physical-address>", and the stable_node address would not have to be displayed above. It looks like the only thing useful in the stable_node structure is the "kpfn" value, which is the pfn of the physical address shown above, correct? I just can't see using the stable_node address as a "handle" in this command. Yes, you obviously need it behind the scenes in order to display the data -- but what good is it to the crash utility user? Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility