7:56 a.m.
----- Original Message -----
于 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.
The command really doesn't show how much physical memory is used for
KSM on a per-guest basis, but rather it just dumps the usage of thousands
of individual pages.
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.
How would there be a memory leak if all of the pages are associated
with mm_structs? And if so, how would this option's output show it?
>
> 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
>
I'm still not convinced -- and you haven't answered -- why this
wouldn't be more reasonable for an extension module?
And by extension, it almost sounds like it would be more useful
to have some kind of "kvm" command that would give this kind of
information along with any other KVM guest-related data?
Dave