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

----- Original Message ----- >> 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 >>> ... So in reality there would be 8713 virtual addresses dumped in the example above?

And taking it a step further, if for example, PID 15864 above were to be a multi-threaded task with 100 threads, the same list of 8713 virtual addresses would be re-displayed 100 times for each PID in the group?

Clearly that would be way too much information for the command to be of much help. Perhaps you could do what the "kmem -[fF]" and "kmem -[sS]" options do, such that "kmem -m" would not display any virtual addresses, and "kmem -M" would be the verbose option that does show them all.

And in the case of mulithreaded tasks, perhaps you could collaborate all of the PID's in a list headed by the thread group leader prior to dumping the virtual page list, i.e., maybe something like: PID: 15864 MAPPING: 8713 [thread group leader] PID: 15865 PID: 15866 PID: 15867 VIRTUAL: 3639c1d000 3639c1e000 3639c1f000 ...