[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F162F28.4010001@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 10:32:08 +0800
From: Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
To: David Ahern <dsahern@...il.com>
CC: Marcelo Tosatti <mtosatti@...hat.com>, Avi Kivity <avi@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, KVM <kvm@...r.kernel.org>
Subject: Re: [PATCH 2/3] KVM: improve trace events of vmexit/mmio/ioport
On 01/18/2012 01:31 AM, David Ahern wrote:
>>>>
>>>> Relying on the existing tracepoints will make the tool work on older
>>>> kernels.
>>>>
>>>
>>>
>>> We can drop all new events, but unfortunately, the information of the origin
>>> tracepoints is not enough, at least vcpu_id need be traced in theses events
>>> to match its events. Yes?
>>
>> Yes, and if you don't add completed events, you'll have to use kvm_entry
>> whose collection adds a lot of overhead.
>
>
> vcpus run as threads and hence have their own tid which is available in
> the perf samples.
>
Nice, thanks for your information, David!
> There is an ongoing 'discussion' about modifying existing tracepoints
> which your proposed patch violates. This is the start of it:
>
Hmm, i think we can still add completed tracepoints in the new version kernel,
if old version kernel is used, we can fall back to use kvm_entry instead?
And there is a exception for mmio read, in current code, the mmio read event is
actually used to trace the time when then read emulation is completed, i think
we can add a tracepoint like mmio_read_begin to trace the start time of mmio read.
So:
- for the new kernel, we use mmio_read_begion and kvm_mmio(READ...) to calculate
start time and end time.
- for the old kernel, we use kvm_exit and kvm_mmio(READ...) to calculate start time
and end time.
Your idea?
--
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