[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <505834D0.2060704@linux.vnet.ibm.com>
Date: Tue, 18 Sep 2012 16:46:08 +0800
From: Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
To: Avi Kivity <avi@...hat.com>
CC: Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, KVM <kvm@...r.kernel.org>
Subject: Re: [PATCH v2] KVM: trace the events of mmu_notifier
On 09/16/2012 05:58 PM, Avi Kivity wrote:
> On 09/14/2012 08:59 AM, Xiao Guangrong wrote:
>> On 09/10/2012 05:26 PM, Xiao Guangrong wrote:
>>> On 09/10/2012 05:09 PM, Avi Kivity wrote:
>>>> On 09/07/2012 09:16 AM, Xiao Guangrong wrote:
>>>>> mmu_notifier is the interface to broadcast the mm events to KVM, the
>>>>> tracepoints introduced in this patch can trace all these events, it is
>>>>> very helpful for us to notice and fix the bug caused by mm
>>>>
>>>> There is nothing kvm specific here. Perhaps this can be made generic
>>>> (with a mm parameter so we can filter by process).
>>>
>>> Hmm, i would like to put these tracepoints in the mmu-lock then we can clearly
>>> know the sequence between mm and kvm mmu. It is useful for us to detect the
>>> issue/race between them.
>>>
>>
>> Ping...?
>
> Sorry. Yes you are right, knowing the exact sequence is valuable. Yet
> it will be hard to associate these events with the mmu since we don't
> have gpas there.
>
Avi,
I have some patches in my local queue which use tracepoints instead of
rmap_printk, they can track rmap_add/rmap_remove/rmap_write_protect.
Though we can not directly get the gfn from these mmu-notifier events, it
can be got from the later events. We can see what mmu is doing when the
notifier events are triggered.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists