All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] perf,x86: Fix shared register mutual exclusion enforcement
@ 2013-06-20 16:42 Stephane Eranian
  2013-06-24  7:46 ` Peter Zijlstra
  2013-06-27  9:01 ` [tip:perf/core] perf/x86: " tip-bot for Stephane Eranian
  0 siblings, 2 replies; 6+ messages in thread
From: Stephane Eranian @ 2013-06-20 16:42 UTC (permalink / raw)
  To: linux-kernel; +Cc: peterz, mingo, vincent.weaver, jolsa, ak


This patch fixes a problem with the shared registers mutual
exclusion code and incremental event scheduling by the
generic perf_event code.

There was a bug whereby the mutual exclusion on the shared
registers was not enforced because of incremental scheduling
abort due to event constraints. As an example on Intel
Nehalem, consider the following events:

group1= L1D_CACHE_LD:E_STATE,OFFCORE_RESPONSE_0:PF_RFO,L1D_CACHE_LD:I_STATE
group2= L1D_CACHE_LD:I_STATE

The L1D_CACHE_LD event can only be measured by 2 counters. Yet, there
are 3 instances here. The first group can be scheduled and is committed.
Then, the generic code tries to schedule group2 and this fails (because
there is no more counter to support the 3rd instance of L1D_CACHE_LD).
But in x86_schedule_events() error path, put_event_contraints() is invoked
on ALL the events and not just the ones that just failed. That causes the
"lock" on the shared offcore_response MSR to be released. Yet the first group
is actually scheduled and is exposed to reprogramming of that shared msr by
the sibling HT thread. In other words, there is no guarantee on what is
measured.

This patch fixes the problem by tagging committed events with the
PERF_X86_EVENT_COMMITTED tag. In the error path of x86_schedule_events(),
only the events NOT tagged have their constraint released. The tag
is eventually removed when the event in descheduled.

Signed-off-by: Stephane Eranian <eranian@google.com>
---
 arch/x86/kernel/cpu/perf_event.c       |   26 +++++++++++++++++++++++++-
 arch/x86/kernel/cpu/perf_event.h       |    3 ++-
 arch/x86/kernel/cpu/perf_event_intel.c |    2 --
 3 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index ab33952..f585ae1 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -726,6 +726,7 @@ int x86_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign)
 {
 	struct event_constraint *c;
 	unsigned long used_mask[BITS_TO_LONGS(X86_PMC_IDX_MAX)];
+	struct perf_event *e;
 	int i, wmin, wmax, num = 0;
 	struct hw_perf_event *hwc;
 
@@ -770,13 +771,31 @@ int x86_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign)
 					 wmax, assign);
 
 	/*
+	 * Mark the event as committed, so we do not put_constraint()
+	 * in case new events are added and fail scheduling.
+	 */
+	if (!num && assign) {
+		for (i = 0; i < n; i++) {
+			e = cpuc->event_list[i];
+			e->hw.flags |= PERF_X86_EVENT_COMMITTED;
+		}
+	}
+	/*
 	 * scheduling failed or is just a simulation,
 	 * free resources if necessary
 	 */
 	if (!assign || num) {
 		for (i = 0; i < n; i++) {
+			e = cpuc->event_list[i];
+			/*
+			 * do not put_constraint() on comitted events,
+			 * because they are good to go
+			 */
+			if ((e->hw.flags & PERF_X86_EVENT_COMMITTED))
+				continue;
+
 			if (x86_pmu.put_event_constraints)
-				x86_pmu.put_event_constraints(cpuc, cpuc->event_list[i]);
+				x86_pmu.put_event_constraints(cpuc, e);
 		}
 	}
 	return num ? -EINVAL : 0;
@@ -1156,6 +1175,11 @@ static void x86_pmu_del(struct perf_event *event, int flags)
 	int i;
 
 	/*
+	 * event is descheduled
+	 */
+	event->hw.flags &= ~PERF_X86_EVENT_COMMITTED;
+
+	/*
 	 * If we're called during a txn, we don't need to do anything.
 	 * The events never got scheduled and ->cancel_txn will truncate
 	 * the event_list.
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 108dc75..5521e04 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -63,11 +63,12 @@ struct event_constraint {
 	int	flags;
 };
 /*
- * struct event_constraint flags
+ * struct hw_perf_event.flags flags
  */
 #define PERF_X86_EVENT_PEBS_LDLAT	0x1 /* ld+ldlat data address sampling */
 #define PERF_X86_EVENT_PEBS_ST		0x2 /* st data address sampling */
 #define PERF_X86_EVENT_PEBS_ST_HSW	0x4 /* haswell style st data sampling */
+#define PERF_X86_EVENT_COMMITTED	0x8 /* event passed commit_txn */
 
 struct amd_nb {
 	int nb_id;  /* NorthBridge id */
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index a6eccf1..7318e77 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1450,7 +1450,6 @@ x86_get_event_constraints(struct cpu_hw_events *cpuc, struct perf_event *event)
 	if (x86_pmu.event_constraints) {
 		for_each_event_constraint(c, x86_pmu.event_constraints) {
 			if ((event->hw.config & c->cmask) == c->code) {
-				/* hw.flags zeroed at initialization */
 				event->hw.flags |= c->flags;
 				return c;
 			}
@@ -1498,7 +1497,6 @@ intel_put_shared_regs_event_constraints(struct cpu_hw_events *cpuc,
 static void intel_put_event_constraints(struct cpu_hw_events *cpuc,
 					struct perf_event *event)
 {
-	event->hw.flags = 0;
 	intel_put_shared_regs_event_constraints(cpuc, event);
 }
 
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] perf,x86: Fix shared register mutual exclusion enforcement
  2013-06-20 16:42 [PATCH v2] perf,x86: Fix shared register mutual exclusion enforcement Stephane Eranian
@ 2013-06-24  7:46 ` Peter Zijlstra
  2013-06-24  8:01   ` Stephane Eranian
  2013-06-27  9:01 ` [tip:perf/core] perf/x86: " tip-bot for Stephane Eranian
  1 sibling, 1 reply; 6+ messages in thread
From: Peter Zijlstra @ 2013-06-24  7:46 UTC (permalink / raw)
  To: Stephane Eranian; +Cc: linux-kernel, mingo, vincent.weaver, jolsa, ak

On Thu, Jun 20, 2013 at 06:42:54PM +0200, Stephane Eranian wrote:
> 
> This patch fixes a problem with the shared registers mutual
> exclusion code and incremental event scheduling by the
> generic perf_event code.
> 
> There was a bug whereby the mutual exclusion on the shared
> registers was not enforced because of incremental scheduling
> abort due to event constraints. As an example on Intel
> Nehalem, consider the following events:
> 
> group1= L1D_CACHE_LD:E_STATE,OFFCORE_RESPONSE_0:PF_RFO,L1D_CACHE_LD:I_STATE
> group2= L1D_CACHE_LD:I_STATE
> 
> The L1D_CACHE_LD event can only be measured by 2 counters. Yet, there
> are 3 instances here. The first group can be scheduled and is committed.
> Then, the generic code tries to schedule group2 and this fails (because
> there is no more counter to support the 3rd instance of L1D_CACHE_LD).
> But in x86_schedule_events() error path, put_event_contraints() is invoked
> on ALL the events and not just the ones that just failed. That causes the
> "lock" on the shared offcore_response MSR to be released. Yet the first group
> is actually scheduled and is exposed to reprogramming of that shared msr by
> the sibling HT thread. In other words, there is no guarantee on what is
> measured.
> 
> This patch fixes the problem by tagging committed events with the
> PERF_X86_EVENT_COMMITTED tag. In the error path of x86_schedule_events(),
> only the events NOT tagged have their constraint released. The tag
> is eventually removed when the event in descheduled.
> 
> Signed-off-by: Stephane Eranian <eranian@google.com>

OK, so I 'accidentally' read the patch again; and noticed something.

In your case above; the get/put constraints are still fully matched.
That is; the first group, which was successful, will not have done a put
yet. So a subsequent get+put should still leave us with a positive 'ref'
count and not undo things.

Only once these events pass through x86_pmu_del() will they get a final
put and the 'ref' count will drop to 0.

Now the problem seems to be the get/put things don't actually count
properly.

However, if we look at __intel_shared_reg_{get,put}_constraints() there
is a refcount in there; namely era->ref; however we don't appear to
clear reg->alloc based on it.

Should we?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] perf,x86: Fix shared register mutual exclusion enforcement
  2013-06-24  7:46 ` Peter Zijlstra
@ 2013-06-24  8:01   ` Stephane Eranian
  2013-06-24 15:48     ` Peter Zijlstra
  0 siblings, 1 reply; 6+ messages in thread
From: Stephane Eranian @ 2013-06-24  8:01 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: LKML, mingo, vincent.weaver, Jiri Olsa, ak

On Mon, Jun 24, 2013 at 9:46 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, Jun 20, 2013 at 06:42:54PM +0200, Stephane Eranian wrote:
>>
>> This patch fixes a problem with the shared registers mutual
>> exclusion code and incremental event scheduling by the
>> generic perf_event code.
>>
>> There was a bug whereby the mutual exclusion on the shared
>> registers was not enforced because of incremental scheduling
>> abort due to event constraints. As an example on Intel
>> Nehalem, consider the following events:
>>
>> group1= L1D_CACHE_LD:E_STATE,OFFCORE_RESPONSE_0:PF_RFO,L1D_CACHE_LD:I_STATE
>> group2= L1D_CACHE_LD:I_STATE
>>
>> The L1D_CACHE_LD event can only be measured by 2 counters. Yet, there
>> are 3 instances here. The first group can be scheduled and is committed.
>> Then, the generic code tries to schedule group2 and this fails (because
>> there is no more counter to support the 3rd instance of L1D_CACHE_LD).
>> But in x86_schedule_events() error path, put_event_contraints() is invoked
>> on ALL the events and not just the ones that just failed. That causes the
>> "lock" on the shared offcore_response MSR to be released. Yet the first group
>> is actually scheduled and is exposed to reprogramming of that shared msr by
>> the sibling HT thread. In other words, there is no guarantee on what is
>> measured.
>>
>> This patch fixes the problem by tagging committed events with the
>> PERF_X86_EVENT_COMMITTED tag. In the error path of x86_schedule_events(),
>> only the events NOT tagged have their constraint released. The tag
>> is eventually removed when the event in descheduled.
>>
>> Signed-off-by: Stephane Eranian <eranian@google.com>
>
> OK, so I 'accidentally' read the patch again; and noticed something.
>
> In your case above; the get/put constraints are still fully matched.
> That is; the first group, which was successful, will not have done a put
> yet. So a subsequent get+put should still leave us with a positive 'ref'
> count and not undo things.
>
You are missing the error path in schedule_events():

 if (!assign || num) {

                for (i = 0; i < n; i++) {
                        if (x86_pmu.put_event_constraints)
                                x86_pmu.put_event_constraints(cpuc,
cpuc->event_list[i]);
                }

        }

That one wipes out on get() even on events that were correctly
schedule in the previous
invocation. So here group2 fails, but it should not release the
constraints from group1.

> Only once these events pass through x86_pmu_del() will they get a final
> put and the 'ref' count will drop to 0.
>
> Now the problem seems to be the get/put things don't actually count
> properly.
>
> However, if we look at __intel_shared_reg_{get,put}_constraints() there
> is a refcount in there; namely era->ref; however we don't appear to
> clear reg->alloc based on it.
>
The era->ref is not used to ref count the number of successful attempts
at scheduling. It is used to count the number of CPU sharing the resource.
So it goes from 0, 1, to 2. You can invoke schedule_events() many more
times. The reg->alloc is a bypass, to avoid checking the shared reg
again and again if it succeeded once.

For a while I thought I could leverage the era->ref to account the get/put.
But it does not work. Because the of the put().


> Should we?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] perf,x86: Fix shared register mutual exclusion enforcement
  2013-06-24  8:01   ` Stephane Eranian
@ 2013-06-24 15:48     ` Peter Zijlstra
  2013-06-25  9:54       ` Stephane Eranian
  0 siblings, 1 reply; 6+ messages in thread
From: Peter Zijlstra @ 2013-06-24 15:48 UTC (permalink / raw)
  To: Stephane Eranian; +Cc: LKML, mingo, vincent.weaver, Jiri Olsa, ak

On Mon, Jun 24, 2013 at 10:01:26AM +0200, Stephane Eranian wrote:

> You are missing the error path in schedule_events():
> 
>  if (!assign || num) {
> 
>                 for (i = 0; i < n; i++) {
>                         if (x86_pmu.put_event_constraints)
>                                 x86_pmu.put_event_constraints(cpuc,
> cpuc->event_list[i]);
>                 }
> 
>         }
> 
> That one wipes out on get() even on events that were correctly
> schedule in the previous
> invocation. So here group2 fails, but it should not release the
> constraints from group1.

What I was saying:

 schedule(group1)
   get_event_constraints() +1
   no error path, no puts

 schedule(group2)
   get_event_constraints() +1
   *fail*
     put_event_constraints() -1

This leaves the constraints of group1 with a net +1 'ref' count and thus
if we were to treat the get/put as such, the put wouldn't be the last
and thus shouldn't release resources.

> > Only once these events pass through x86_pmu_del() will they get a final
> > put and the 'ref' count will drop to 0.
> >
> > Now the problem seems to be the get/put things don't actually count
> > properly.
> >
> > However, if we look at __intel_shared_reg_{get,put}_constraints() there
> > is a refcount in there; namely era->ref; however we don't appear to
> > clear reg->alloc based on it.
> >
> The era->ref is not used to ref count the number of successful attempts
> at scheduling. It is used to count the number of CPU sharing the resource.
> So it goes from 0, 1, to 2. You can invoke schedule_events() many more
> times. The reg->alloc is a bypass, to avoid checking the shared reg
> again and again if it succeeded once.

Oh right, I knew I was missing something..  :/

> For a while I thought I could leverage the era->ref to account the get/put.
> But it does not work. Because the of the put().

Crud, right you are. 

Also, I don't think we could even use them as I outlined; suppose it
would have worked; then we'd have:

  schedule(group1)
    get_event_constraints() +1

  schedule(group2)
    get_event_constraints() +1

And we'd be stuck with a ref of 2, the put at x86_pmu_del() would never
be sufficient to drop them back to 0 again.

A well, your patch does indeed make it work so I'll grab that.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] perf,x86: Fix shared register mutual exclusion enforcement
  2013-06-24 15:48     ` Peter Zijlstra
@ 2013-06-25  9:54       ` Stephane Eranian
  0 siblings, 0 replies; 6+ messages in thread
From: Stephane Eranian @ 2013-06-25  9:54 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: LKML, mingo, vincent.weaver, Jiri Olsa, ak

On Mon, Jun 24, 2013 at 5:48 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, Jun 24, 2013 at 10:01:26AM +0200, Stephane Eranian wrote:
>
>> You are missing the error path in schedule_events():
>>
>>  if (!assign || num) {
>>
>>                 for (i = 0; i < n; i++) {
>>                         if (x86_pmu.put_event_constraints)
>>                                 x86_pmu.put_event_constraints(cpuc,
>> cpuc->event_list[i]);
>>                 }
>>
>>         }
>>
>> That one wipes out on get() even on events that were correctly
>> schedule in the previous
>> invocation. So here group2 fails, but it should not release the
>> constraints from group1.
>
> What I was saying:
>
>  schedule(group1)
>    get_event_constraints() +1
>    no error path, no puts
>
>  schedule(group2)
>    get_event_constraints() +1
>    *fail*
>      put_event_constraints() -1
>
> This leaves the constraints of group1 with a net +1 'ref' count and thus
> if we were to treat the get/put as such, the put wouldn't be the last
> and thus shouldn't release resources.
>
>> > Only once these events pass through x86_pmu_del() will they get a final
>> > put and the 'ref' count will drop to 0.
>> >
>> > Now the problem seems to be the get/put things don't actually count
>> > properly.
>> >
>> > However, if we look at __intel_shared_reg_{get,put}_constraints() there
>> > is a refcount in there; namely era->ref; however we don't appear to
>> > clear reg->alloc based on it.
>> >
>> The era->ref is not used to ref count the number of successful attempts
>> at scheduling. It is used to count the number of CPU sharing the resource.
>> So it goes from 0, 1, to 2. You can invoke schedule_events() many more
>> times. The reg->alloc is a bypass, to avoid checking the shared reg
>> again and again if it succeeded once.
>
> Oh right, I knew I was missing something..  :/
>
>> For a while I thought I could leverage the era->ref to account the get/put.
>> But it does not work. Because the of the put().
>
> Crud, right you are.
>
> Also, I don't think we could even use them as I outlined; suppose it
> would have worked; then we'd have:
>
>   schedule(group1)
>     get_event_constraints() +1
>
>   schedule(group2)
>     get_event_constraints() +1
>
> And we'd be stuck with a ref of 2, the put at x86_pmu_del() would never
> be sufficient to drop them back to 0 again.
>
Yes, imagine we add 3 groups:

    schedule(grp1)  grp1=1

    schedule(grp2) grp1=2, grp2 =1

   schedule(grp3) -> *failed*, put, grp1=2, grp2=1, grp3=0

And then in the del side, we'd have no way of knowing that to get
the current assignment we incrementally scheduled twice, and thus
we have to do grp1 -=2 and not just -=1.


> A well, your patch does indeed make it work so I'll grab that.

Thanks,

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [tip:perf/core] perf/x86: Fix shared register mutual exclusion enforcement
  2013-06-20 16:42 [PATCH v2] perf,x86: Fix shared register mutual exclusion enforcement Stephane Eranian
  2013-06-24  7:46 ` Peter Zijlstra
@ 2013-06-27  9:01 ` tip-bot for Stephane Eranian
  1 sibling, 0 replies; 6+ messages in thread
From: tip-bot for Stephane Eranian @ 2013-06-27  9:01 UTC (permalink / raw)
  To: linux-tip-commits; +Cc: linux-kernel, eranian, hpa, mingo, peterz, tglx

Commit-ID:  2f7f73a52078b667d64df16eaebdb97d98c9a410
Gitweb:     http://git.kernel.org/tip/2f7f73a52078b667d64df16eaebdb97d98c9a410
Author:     Stephane Eranian <eranian@google.com>
AuthorDate: Thu, 20 Jun 2013 18:42:54 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 26 Jun 2013 21:58:49 +0200

perf/x86: Fix shared register mutual exclusion enforcement

This patch fixes a problem with the shared registers mutual
exclusion code and incremental event scheduling by the
generic perf_event code.

There was a bug whereby the mutual exclusion on the shared
registers was not enforced because of incremental scheduling
abort due to event constraints. As an example on Intel
Nehalem, consider the following events:

group1= L1D_CACHE_LD:E_STATE,OFFCORE_RESPONSE_0:PF_RFO,L1D_CACHE_LD:I_STATE
group2= L1D_CACHE_LD:I_STATE

The L1D_CACHE_LD event can only be measured by 2 counters. Yet, there
are 3 instances here. The first group can be scheduled and is committed.
Then, the generic code tries to schedule group2 and this fails (because
there is no more counter to support the 3rd instance of L1D_CACHE_LD).
But in x86_schedule_events() error path, put_event_contraints() is invoked
on ALL the events and not just the ones that just failed. That causes the
"lock" on the shared offcore_response MSR to be released. Yet the first group
is actually scheduled and is exposed to reprogramming of that shared msr by
the sibling HT thread. In other words, there is no guarantee on what is
measured.

This patch fixes the problem by tagging committed events with the
PERF_X86_EVENT_COMMITTED tag. In the error path of x86_schedule_events(),
only the events NOT tagged have their constraint released. The tag
is eventually removed when the event in descheduled.

Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20130620164254.GA3556@quad
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/kernel/cpu/perf_event.c       | 26 +++++++++++++++++++++++++-
 arch/x86/kernel/cpu/perf_event.h       |  3 ++-
 arch/x86/kernel/cpu/perf_event_intel.c |  2 --
 3 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index afc2413..9e581c5 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -726,6 +726,7 @@ int x86_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign)
 {
 	struct event_constraint *c;
 	unsigned long used_mask[BITS_TO_LONGS(X86_PMC_IDX_MAX)];
+	struct perf_event *e;
 	int i, wmin, wmax, num = 0;
 	struct hw_perf_event *hwc;
 
@@ -770,13 +771,31 @@ int x86_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign)
 					 wmax, assign);
 
 	/*
+	 * Mark the event as committed, so we do not put_constraint()
+	 * in case new events are added and fail scheduling.
+	 */
+	if (!num && assign) {
+		for (i = 0; i < n; i++) {
+			e = cpuc->event_list[i];
+			e->hw.flags |= PERF_X86_EVENT_COMMITTED;
+		}
+	}
+	/*
 	 * scheduling failed or is just a simulation,
 	 * free resources if necessary
 	 */
 	if (!assign || num) {
 		for (i = 0; i < n; i++) {
+			e = cpuc->event_list[i];
+			/*
+			 * do not put_constraint() on comitted events,
+			 * because they are good to go
+			 */
+			if ((e->hw.flags & PERF_X86_EVENT_COMMITTED))
+				continue;
+
 			if (x86_pmu.put_event_constraints)
-				x86_pmu.put_event_constraints(cpuc, cpuc->event_list[i]);
+				x86_pmu.put_event_constraints(cpuc, e);
 		}
 	}
 	return num ? -EINVAL : 0;
@@ -1156,6 +1175,11 @@ static void x86_pmu_del(struct perf_event *event, int flags)
 	int i;
 
 	/*
+	 * event is descheduled
+	 */
+	event->hw.flags &= ~PERF_X86_EVENT_COMMITTED;
+
+	/*
 	 * If we're called during a txn, we don't need to do anything.
 	 * The events never got scheduled and ->cancel_txn will truncate
 	 * the event_list.
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 4809f07..97e557b 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -63,11 +63,12 @@ struct event_constraint {
 	int	flags;
 };
 /*
- * struct event_constraint flags
+ * struct hw_perf_event.flags flags
  */
 #define PERF_X86_EVENT_PEBS_LDLAT	0x1 /* ld+ldlat data address sampling */
 #define PERF_X86_EVENT_PEBS_ST		0x2 /* st data address sampling */
 #define PERF_X86_EVENT_PEBS_ST_HSW	0x4 /* haswell style st data sampling */
+#define PERF_X86_EVENT_COMMITTED	0x8 /* event passed commit_txn */
 
 struct amd_nb {
 	int nb_id;  /* NorthBridge id */
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index 5877f37..fbc9210 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1450,7 +1450,6 @@ x86_get_event_constraints(struct cpu_hw_events *cpuc, struct perf_event *event)
 	if (x86_pmu.event_constraints) {
 		for_each_event_constraint(c, x86_pmu.event_constraints) {
 			if ((event->hw.config & c->cmask) == c->code) {
-				/* hw.flags zeroed at initialization */
 				event->hw.flags |= c->flags;
 				return c;
 			}
@@ -1498,7 +1497,6 @@ intel_put_shared_regs_event_constraints(struct cpu_hw_events *cpuc,
 static void intel_put_event_constraints(struct cpu_hw_events *cpuc,
 					struct perf_event *event)
 {
-	event->hw.flags = 0;
 	intel_put_shared_regs_event_constraints(cpuc, event);
 }
 

^ permalink raw reply related	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-06-27  9:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-20 16:42 [PATCH v2] perf,x86: Fix shared register mutual exclusion enforcement Stephane Eranian
2013-06-24  7:46 ` Peter Zijlstra
2013-06-24  8:01   ` Stephane Eranian
2013-06-24 15:48     ` Peter Zijlstra
2013-06-25  9:54       ` Stephane Eranian
2013-06-27  9:01 ` [tip:perf/core] perf/x86: " tip-bot for Stephane Eranian

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.