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

Zhang Yanfei zhangyanfei at cn.fujitsu.com
Wed Mar 27 02:26:12 UTC 2013


于 2013年03月26日 02:21, Dave Anderson 写道:
> 
> 
> ----- 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?

No, it is just an example, but this number may be possible in reality.

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

this does not happen. ksmd registers a task's "mm" into its scan target,
so it doesn't care if it is a multi-threaded task since all the threads
share the same mm.

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

This is ok for me.

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

As explained above, the output will only display the thread group leader.

I'll send the v2 patch.

Thanks
Zhang





More information about the Crash-utility mailing list