2:29 a.m.
于 2013年04月06日 02:30, Dave Anderson 写道:
----- Original Message -----
>
> ----- Original Message -----
>>
Hello Zhang,
I have spent some time testing/playing with this with a local
system set up with 4 KVM guests, and also with the sample
vmcore that you sent to me.
Thanks very much.
The problem I have is that I find it difficult to justify adding
the command to the base crash utility. It's hard to conceive
of a situation where the command would be useful in a kernel
debugging session -- that is unless perhaps you were actually
developing the KSM feature, or if the KSM subsystem were to be
prone to breakage, which doesn't seem to be the case.
Sorry for this delayed answer.
Below is our situations where the command would be useful.
o To find out for what purpose given physical pages are used from the
number of and contents of physical pages among guest machines.
We have faced the situation that memory compaction processing
increased CPU use ratio. The processing tried to parepare 2MB
contiguous pages requested by THP, but there were unremoval pages
caused by KSM. The pages controlled by KSM, i.e. the ones referenced
by stable_node tree, are unmovable. We can already find where are
unmovable by the existing crash's feature. So, now we need to any
way of checking if the unmovable pages are controlled by KSM,
quickly.
o To find out actual amount of physical memory used by guest machines.
RSS information in ps command and rss in mm_struct objects doesn't
consider the physical pages shared by KSM. We need to look up KSM
data structure in order to estimate total amount of physical memory
actually used. Also, although KSM provides stastical information, it
includes total amount of physical memory throughout all the guest
machines only. We want to see the same information in smaller granuality,
such as per a guest machine.
Typical case where we want to use this featuere is a memory leak. If
system shows behaviour like memory leak, we need to analyize actual
memory consumption over a whole system accurately including the
physical memory used by guest machines.
It also could be argued that it's output is more relevant to
the "vm" command instead of the "kmem" command. In other words,
it's really an abstraction of the virtual-to-physical aspect
of the "vm -p" output, but specific to only "qemu-kvm" tasks.
Hmmm... What we mainly process is the rb_tree that manages all
the ksm pages. It is not related to a single vm of a task. So
I still think kmem may be more relevant.
Now, like I mentioned before, I'm sure you do have your reasons,
but certainly have not responded as to why this functionality
is not more suitable as an extension module? To me it makes
perfect sense as a standalone command.
And to that end, I have flipped your patch into a "ksm" extension
module, which I've attached. I've slightly tinkered with the
output display, and given that it's an standalone command, replaced
the -m and -M options with a -v for the virtual addresses dump.
The help page looks like this:
crash> help ksm
NAME
ksm - kernel samepage merging (KSM) information
SYNOPSIS
ksm [-v] [[-p] address ...]
DESCRIPTION
This command displays information about all KSM pages currently
in use. For each KSM page, the display includes its stable_node
address, its page struct address, its physical address, the TGID/PID
for each task that is using the page, and the number of mappings in
the task's address space for the page.
-v also dump each virtual address in a PID's virtual address
space that maps the KSM page.
address restricts the output to the KSM data associated with a
stable_node address, a page's physical address, or a page
pointer.
-p specifies that the address argument is a physical address,
for architectures that require it.
EXAMPLE
Display information about all KSM pages:
crash> ksm
PAGE: ffffea000ae7f6a8
STABLE_NODE: ffff8806248c2d80
PHYSICAL ADDRESS: 31db43000
PID: 2205 MAPPINGS: 2
PAGE: ffffea000ae800f0
STABLE_NODE: ffff880624aa57b8
PHYSICAL ADDRESS: 31db72000
PID: 2205 MAPPINGS: 2
PAGE: ffffea000ae7f8d8
STABLE_NODE: ffff8806248c2dd0
PHYSICAL ADDRESS: 31db4d000
PID: 2205 MAPPINGS: 2
...
Display all information about the KSM page whose physical
address is 0x626e60000:
crash> ksm -v 626e60000
PAGE: ffffea0015882500
STABLE_NODE: ffff88028b2af3d0
PHYSICAL ADDRESS: 626e60000
PID: 2603 MAPPINGS: 8
VIRTUAL:
7ff46bcb4000
7ff46bcad000
7ff46bc9f000
7ff46bc7c000
7ff46bc6e000
7ff46bc67000
7ff46bc60000
7ff46bc59000
crash>
I've attached the ksm.c extension module for you to check out.
Just throw it into a crash-<version>/extensions subdirectory,
enter "make extensions", and it will build automatically.
For that matter, you may even want to consider adding additional
KSM-related functionality to the command? But anyway, with your
approval, I'd like to add it to the extensions web page.
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility