On 07/21/2012 02:34 AM, David Ahern wrote:
> On 7/11/12 1:10 AM, Gleb Natapov wrote:
>> Looks like Avi is right about the overshoot. Can you test something
>> like this?
>>
>> diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
>> b/arch/x86/kernel/cpu/perf_event_intel.c
>> index 166546e..5fb371a 1
On 7/9/12 8:47 AM, Peter Zijlstra wrote:
On Mon, 2012-07-09 at 17:39 +0300, Avi Kivity wrote:
Disabling PEBS events for guests isn't pretty though..
We already have atomic MSR switching at guest entry/exit time. So it's
not pretty in terms of not getting full profiling, but the code won't be
On 7/11/12 1:10 AM, Gleb Natapov wrote:
Looks like Avi is right about the overshoot. Can you test something like this?
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 166546e..5fb371a 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/ar
On 7/12/12 10:06 AM, Gleb Natapov wrote:
I started with cycles:pp; should not really matter - they all need
to work without blowing up VMs (cycles:p, cycles:pH, cycles:pG,
cycles:pp, cycles:ppH, cycles:ppG).
cycles:ppG and cycles:pG should be illegal. Peter's patch takes care of
this. Others sho
On 7/15/12 7:03 AM, Avi Kivity wrote:
I assume 'h' means profiling the hypervisor from a guest (i.e. xen dom0)?
I do not think so. It does not appear to do anything on x86.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
On 7/12/12 10:13 AM, Gleb Natapov wrote:
On Thu, Jul 12, 2012 at 07:06:35PM +0300, Gleb Natapov wrote:
So, is the idea of your patch to not enable the PEBS in guest mode?
Yes, the idea of my patch is to disable PEBS and the guest entry.
BTW what is you host cpu? My patch works only for thos
On 07/15/2012 04:00 PM, David Ahern wrote:
> On 7/15/12 2:07 AM, Avi Kivity wrote:
>> On 07/12/2012 07:06 PM, Gleb Natapov wrote:
Note the :pH this time.
>>> I am not sure what perf kvm does with :pH modifier, but H modifier does
>>> not make sense with perf kvm and should be reported as
On 7/15/12 2:07 AM, Avi Kivity wrote:
On 07/12/2012 07:06 PM, Gleb Natapov wrote:
Note the :pH this time.
I am not sure what perf kvm does with :pH modifier, but H modifier does
not make sense with perf kvm and should be reported as an error by perf tool.
Maybe it should refer to the guest v
On 07/12/2012 07:06 PM, Gleb Natapov wrote:
>>
>> Note the :pH this time.
> I am not sure what perf kvm does with :pH modifier, but H modifier does
> not make sense with perf kvm and should be reported as an error by perf tool.
Maybe it should refer to the guest vs. the nested guest...
Well that
On Thu, 2012-07-12 at 19:13 +0300, Gleb Natapov wrote:
> BTW what is you host cpu? My patch works only for those that have global
> control register to disable PMU events, but that should cover most of
> moder cpus.
That covers everything but core and p4, and I don't think we support
PEBS on eith
On Thu, Jul 12, 2012 at 07:06:35PM +0300, Gleb Natapov wrote:
> >
> > So, is the idea of your patch to not enable the PEBS in guest mode?
> >
> Yes, the idea of my patch is to disable PEBS and the guest entry.
>
BTW what is you host cpu? My patch works only for those that have global
control reg
On Thu, Jul 12, 2012 at 09:20:53AM -0600, David Ahern wrote:
> On 7/11/12 10:29 PM, Gleb Natapov wrote:
> >On Wed, Jul 11, 2012 at 10:11:57PM -0600, David Ahern wrote:
> >>On 7/11/12 3:53 AM, Gleb Natapov wrote:
> >>>On Wed, Jul 11, 2012 at 11:49:47AM +0200, Peter Zijlstra wrote:
> On Wed, 2012
On 7/11/12 10:29 PM, Gleb Natapov wrote:
On Wed, Jul 11, 2012 at 10:11:57PM -0600, David Ahern wrote:
On 7/11/12 3:53 AM, Gleb Natapov wrote:
On Wed, Jul 11, 2012 at 11:49:47AM +0200, Peter Zijlstra wrote:
On Wed, 2012-07-11 at 10:10 +0300, Gleb Natapov wrote:
Looks like Avi is right about t
On Wed, Jul 11, 2012 at 10:11:57PM -0600, David Ahern wrote:
> On 7/11/12 3:53 AM, Gleb Natapov wrote:
> >On Wed, Jul 11, 2012 at 11:49:47AM +0200, Peter Zijlstra wrote:
> >>On Wed, 2012-07-11 at 10:10 +0300, Gleb Natapov wrote:
> >>
> >>>Looks like Avi is right about the overshoot. Can you test so
On 7/11/12 3:53 AM, Gleb Natapov wrote:
On Wed, Jul 11, 2012 at 11:49:47AM +0200, Peter Zijlstra wrote:
On Wed, 2012-07-11 at 10:10 +0300, Gleb Natapov wrote:
Looks like Avi is right about the overshoot. Can you test something like this?
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/
On 7/11/12 3:53 AM, Gleb Natapov wrote:
On Wed, Jul 11, 2012 at 11:49:47AM +0200, Peter Zijlstra wrote:
On Wed, 2012-07-11 at 10:10 +0300, Gleb Natapov wrote:
Looks like Avi is right about the overshoot. Can you test something like this?
I head to the airport in a few minutes; I'll try it ou
On Wed, Jul 11, 2012 at 11:49:47AM +0200, Peter Zijlstra wrote:
> On Wed, 2012-07-11 at 10:10 +0300, Gleb Natapov wrote:
>
> > Looks like Avi is right about the overshoot. Can you test something like
> > this?
> >
> > diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
> > b/arch/x86/kernel/cpu
On Wed, 2012-07-11 at 10:10 +0300, Gleb Natapov wrote:
> Looks like Avi is right about the overshoot. Can you test something like this?
>
> diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
> b/arch/x86/kernel/cpu/perf_event_intel.c
> index 166546e..5fb371a 100644
> --- a/arch/x86/kernel/cpu/p
On Tue, Jul 10, 2012 at 05:38:40PM -0600, David Ahern wrote:
> On 7/9/12 8:59 AM, Peter Zijlstra wrote:
> >On Mon, 2012-07-09 at 17:51 +0300, Avi Kivity wrote:
> >>On 07/09/2012 05:49 PM, Peter Zijlstra wrote:
> >>>On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
>
> I found this test
On 7/9/12 8:59 AM, Peter Zijlstra wrote:
On Mon, 2012-07-09 at 17:51 +0300, Avi Kivity wrote:
On 07/09/2012 05:49 PM, Peter Zijlstra wrote:
On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
I found this testing changes to perf-kvm, but found the problem extends
to just perf-record. With p
On 7/9/12 8:58 AM, David Ahern wrote:
On 7/9/12 8:52 AM, David Ahern wrote:
On 7/9/12 8:49 AM, Peter Zijlstra wrote:
On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
I found this testing changes to perf-kvm, but found the problem extends
to just perf-record. With perf-record exclude_gues
On Mon, 2012-07-09 at 17:51 +0300, Avi Kivity wrote:
> On 07/09/2012 05:49 PM, Peter Zijlstra wrote:
> > On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
> >>
> >> I found this testing changes to perf-kvm, but found the problem extends
> >> to just perf-record. With perf-record exclude_guest
On 7/9/12 8:52 AM, David Ahern wrote:
On 7/9/12 8:49 AM, Peter Zijlstra wrote:
On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
I found this testing changes to perf-kvm, but found the problem extends
to just perf-record. With perf-record exclude_guest defaults to 1. See
tools/perf/util/ut
On Mon, Jul 09, 2012 at 05:54:42PM +0300, Gleb Natapov wrote:
> On Mon, Jul 09, 2012 at 05:51:29PM +0300, Avi Kivity wrote:
> > On 07/09/2012 05:49 PM, Peter Zijlstra wrote:
> > > On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
> > >>
> > >> I found this testing changes to perf-kvm, but foun
On Mon, Jul 09, 2012 at 05:51:29PM +0300, Avi Kivity wrote:
> On 07/09/2012 05:49 PM, Peter Zijlstra wrote:
> > On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
> >>
> >> I found this testing changes to perf-kvm, but found the problem extends
> >> to just perf-record. With perf-record exclud
On 7/9/12 8:49 AM, Peter Zijlstra wrote:
On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
I found this testing changes to perf-kvm, but found the problem extends
to just perf-record. With perf-record exclude_guest defaults to 1. See
tools/perf/util/util.c, event_attr_init().
You lost me
On 07/09/2012 05:49 PM, Peter Zijlstra wrote:
> On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
>>
>> I found this testing changes to perf-kvm, but found the problem extends
>> to just perf-record. With perf-record exclude_guest defaults to 1. See
>> tools/perf/util/util.c, event_attr_init
On Mon, 2012-07-09 at 08:47 -0600, David Ahern wrote:
>
> I found this testing changes to perf-kvm, but found the problem extends
> to just perf-record. With perf-record exclude_guest defaults to 1. See
> tools/perf/util/util.c, event_attr_init().
You lost me there.. so perf-record defaults to
On Mon, 2012-07-09 at 17:39 +0300, Avi Kivity wrote:
> > Disabling PEBS events for guests isn't pretty though..
>
> We already have atomic MSR switching at guest entry/exit time. So it's
> not pretty in terms of not getting full profiling, but the code won't be
> too hard. Basically we just hav
On 7/9/12 8:39 AM, Avi Kivity wrote:
On 07/09/2012 05:24 PM, Peter Zijlstra wrote:
On Mon, 2012-07-09 at 17:19 +0300, Gleb Natapov wrote:
Yes, this is knows problem that I can't find time to fix. The crash is
cause by CPU using host PEBS virtual address while guest is running
which causes guest
On 07/09/2012 05:24 PM, Peter Zijlstra wrote:
> On Mon, 2012-07-09 at 17:19 +0300, Gleb Natapov wrote:
>> Yes, this is knows problem that I can't find time to fix. The crash is
>> cause by CPU using host PEBS virtual address while guest is running
>> which causes guest memory corruption. We should
On Mon, Jul 09, 2012 at 04:24:04PM +0200, Peter Zijlstra wrote:
> On Mon, 2012-07-09 at 17:19 +0300, Gleb Natapov wrote:
> > Yes, this is knows problem that I can't find time to fix. The crash is
> > cause by CPU using host PEBS virtual address while guest is running
> > which causes guest memory c
On Mon, 2012-07-09 at 17:19 +0300, Gleb Natapov wrote:
> Yes, this is knows problem that I can't find time to fix. The crash is
> cause by CPU using host PEBS virtual address while guest is running
> which causes guest memory corruption. We should disable evens that use
> PEBS at the guest entry.
On Mon, Jul 09, 2012 at 08:12:40AM -0600, David Ahern wrote:
> This is 100% reproducible with Fedora 17, 3.4.2-1.fc16.x86_64 kernel.
>
> Using the precise attribute (:p or :pp) with perf-record, eg,
>
> perf record -e cycles:p -ag -- sleep 10
>
> All running VMs are killed. The VMs appear to be
This is 100% reproducible with Fedora 17, 3.4.2-1.fc16.x86_64 kernel.
Using the precise attribute (:p or :pp) with perf-record, eg,
perf record -e cycles:p -ag -- sleep 10
All running VMs are killed. The VMs appear to be restarted but crash on
restart.
From one of the VMs that has the consol
35 matches
Mail list logo
