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
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 100644
---
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
+++
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
+++
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/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
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
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
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
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
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's a
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
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 an error by
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
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
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
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
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
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,
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
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
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-07-11 at
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 register
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 either
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
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
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
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
> >
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
> ---
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
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 testing changes to
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
---
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
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
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
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 something like
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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 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
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 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
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 have to
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 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 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 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 exclude_guest
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 found the problem
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
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 defaults
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
70 matches
Mail list logo
