Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 10:45:02AM -0400, Vince Weaver wrote:
> 
> On Tue, 25 Sep 2012, Cyrill Gorcunov wrote:
> 
> > So guys, if understand all things correctly it's supposed to use some
> > -1/-2 as initial @config value for unsupported events, right? Vince,
> > may not it be easier to use bit 19 as a flag of valid event and clear
> > it when you write to msr, thus we will not have to change "zero is reserved"
> > semantics (otoh i'm not sure if it won't become a problem somewhere in
> > future with some new cpu :)
> 
> Well, we wouldn't want to use a reserved bit.
> In theory we could re-use bit 22 (enable) or bit 20 (APIC enable)
> because those values should in theory be set elsewhere and could probably
> be masked out at an appropriate place.
> 
> Is -2 really a valid cache event on Pentium 4?

Nope, there can't be config with -2 as valid value. So we can use -2
if needed as far as I can tell (the -1 can't be valid as well).

> Though I admit patching all of the various PMU drivers to use -1/-2 rather 
> than 0/-1 will be a pain, especially as many of them just default to 0
> with no initialization currently.

Yup, but if it'll be needed I can tune up p4 code (thought i'll need
some help in testing since i've no p4 cpu anymore).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Vince Weaver

On Tue, 25 Sep 2012, Cyrill Gorcunov wrote:

> So guys, if understand all things correctly it's supposed to use some
> -1/-2 as initial @config value for unsupported events, right? Vince,
> may not it be easier to use bit 19 as a flag of valid event and clear
> it when you write to msr, thus we will not have to change "zero is reserved"
> semantics (otoh i'm not sure if it won't become a problem somewhere in
> future with some new cpu :)

Well, we wouldn't want to use a reserved bit.
In theory we could re-use bit 22 (enable) or bit 20 (APIC enable)
because those values should in theory be set elsewhere and could probably
be masked out at an appropriate place.

Is -2 really a valid cache event on Pentium 4?

Though I admit patching all of the various PMU drivers to use -1/-2 rather 
than 0/-1 will be a pain, especially as many of them just default to 0
with no initialization currently. 

Vince Weaver
vincent.wea...@maine.edu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 02:01:26PM +0200, Peter Zijlstra wrote:
> On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:
> 
> > Guys, letme re-read this whole mail thread first since I have no clue
> > what this remapping about ;)
> 
> x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
> config values to mean -ENOENT and -EINVAL resp.
> 
> This means neither config value can be a 'real' event. Now it turns out
> Xeon-Phi has an actual event 0, which is masked by these special case
> thingies.

So guys, if understand all things correctly it's supposed to use some
-1/-2 as initial @config value for unsupported events, right? Vince,
may not it be easier to use bit 19 as a flag of valid event and clear
it when you write to msr, thus we will not have to change "zero is reserved"
semantics (otoh i'm not sure if it won't become a problem somewhere in
future with some new cpu :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 04:22:29PM +0400, Cyrill Gorcunov wrote:
> On Tue, Sep 25, 2012 at 02:05:58PM +0200, stephane eranian wrote:
> > On Tue, Sep 25, 2012 at 2:01 PM, Peter Zijlstra  
> > wrote:
> > > On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:
> > >
> > >> Guys, letme re-read this whole mail thread first since I have no clue
> > >> what this remapping about ;)
> > >
> > > x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
> > > config values to mean -ENOENT and -EINVAL resp.
> > >
> > > This means neither config value can be a 'real' event. Now it turns out
> > > Xeon-Phi has an actual event 0, which is masked by these special case
> > > thingies.
> > 
> > Then how about using -1 or -2 for ENOENT and EINVAL?
> 
> -2 can't be a valid p4 config as far as i can tell.

I mean such value can be easily recognized by p4 code and treated
specially if needed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 02:05:58PM +0200, stephane eranian wrote:
> On Tue, Sep 25, 2012 at 2:01 PM, Peter Zijlstra  
> wrote:
> > On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:
> >
> >> Guys, letme re-read this whole mail thread first since I have no clue
> >> what this remapping about ;)
> >
> > x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
> > config values to mean -ENOENT and -EINVAL resp.
> >
> > This means neither config value can be a 'real' event. Now it turns out
> > Xeon-Phi has an actual event 0, which is masked by these special case
> > thingies.
> 
> Then how about using -1 or -2 for ENOENT and EINVAL?

-2 can't be a valid p4 config as far as i can tell.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread stephane eranian
On Tue, Sep 25, 2012 at 2:01 PM, Peter Zijlstra  wrote:
> On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:
>
>> Guys, letme re-read this whole mail thread first since I have no clue
>> what this remapping about ;)
>
> x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
> config values to mean -ENOENT and -EINVAL resp.
>
> This means neither config value can be a 'real' event. Now it turns out
> Xeon-Phi has an actual event 0, which is masked by these special case
> thingies.

Then how about using -1 or -2 for ENOENT and EINVAL?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Peter Zijlstra
On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:

> Guys, letme re-read this whole mail thread first since I have no clue
> what this remapping about ;)

x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
config values to mean -ENOENT and -EINVAL resp.

This means neither config value can be a 'real' event. Now it turns out
Xeon-Phi has an actual event 0, which is masked by these special case
thingies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 03:42:25PM +0400, Cyrill Gorcunov wrote:
> On Tue, Sep 25, 2012 at 01:32:38PM +0200, Peter Zijlstra wrote:
> > On Thu, 2012-09-20 at 13:03 -0400, Vince Weaver wrote:
> > > One additional complication:  some of the cache events map to 
> > > event "0".  This causes problems because the generic events code
> > > assumes "0" means not-available.  I'm not sure the best way to address
> > > that problem. 
> > 
> > For all except P4 we could remap the 0 value to -2, that has all high
> > bits set (like the -1) which aren't used by hardware.
> > 
> > P4 is stuffing two registers in the 64bit config space and actually has
> > them all in use I think.. Cyrill?
> 
> Yeah, we use almost all 64 bits in config. I tried to describe the bitmaps
> in perf_event_p4.h (see Notes on internal configuration of ESCR+CCCR tuples).
> 
> Guys, letme re-read this whole mail thread first since I have no clue
> what this remapping about ;)

If we need some special mark in config I can try to free hight bit in
@config and move it somehwere in low 32 bits (there are bits 28-29 which
i can use for that). Ie I can provide the sign bit, would it be enough?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 01:32:38PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-20 at 13:03 -0400, Vince Weaver wrote:
> > One additional complication:  some of the cache events map to 
> > event "0".  This causes problems because the generic events code
> > assumes "0" means not-available.  I'm not sure the best way to address
> > that problem. 
> 
> For all except P4 we could remap the 0 value to -2, that has all high
> bits set (like the -1) which aren't used by hardware.
> 
> P4 is stuffing two registers in the 64bit config space and actually has
> them all in use I think.. Cyrill?

Yeah, we use almost all 64 bits in config. I tried to describe the bitmaps
in perf_event_p4.h (see Notes on internal configuration of ESCR+CCCR tuples).

Guys, letme re-read this whole mail thread first since I have no clue
what this remapping about ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Peter Zijlstra
On Thu, 2012-09-20 at 13:03 -0400, Vince Weaver wrote:
> One additional complication:  some of the cache events map to 
> event "0".  This causes problems because the generic events code
> assumes "0" means not-available.  I'm not sure the best way to address
> that problem. 

For all except P4 we could remap the 0 value to -2, that has all high
bits set (like the -1) which aren't used by hardware.

P4 is stuffing two registers in the 64bit config space and actually has
them all in use I think.. Cyrill?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Peter Zijlstra
On Thu, 2012-09-20 at 13:03 -0400, Vince Weaver wrote:
 One additional complication:  some of the cache events map to 
 event 0.  This causes problems because the generic events code
 assumes 0 means not-available.  I'm not sure the best way to address
 that problem. 

For all except P4 we could remap the 0 value to -2, that has all high
bits set (like the -1) which aren't used by hardware.

P4 is stuffing two registers in the 64bit config space and actually has
them all in use I think.. Cyrill?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 01:32:38PM +0200, Peter Zijlstra wrote:
 On Thu, 2012-09-20 at 13:03 -0400, Vince Weaver wrote:
  One additional complication:  some of the cache events map to 
  event 0.  This causes problems because the generic events code
  assumes 0 means not-available.  I'm not sure the best way to address
  that problem. 
 
 For all except P4 we could remap the 0 value to -2, that has all high
 bits set (like the -1) which aren't used by hardware.
 
 P4 is stuffing two registers in the 64bit config space and actually has
 them all in use I think.. Cyrill?

Yeah, we use almost all 64 bits in config. I tried to describe the bitmaps
in perf_event_p4.h (see Notes on internal configuration of ESCR+CCCR tuples).

Guys, letme re-read this whole mail thread first since I have no clue
what this remapping about ;)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 03:42:25PM +0400, Cyrill Gorcunov wrote:
 On Tue, Sep 25, 2012 at 01:32:38PM +0200, Peter Zijlstra wrote:
  On Thu, 2012-09-20 at 13:03 -0400, Vince Weaver wrote:
   One additional complication:  some of the cache events map to 
   event 0.  This causes problems because the generic events code
   assumes 0 means not-available.  I'm not sure the best way to address
   that problem. 
  
  For all except P4 we could remap the 0 value to -2, that has all high
  bits set (like the -1) which aren't used by hardware.
  
  P4 is stuffing two registers in the 64bit config space and actually has
  them all in use I think.. Cyrill?
 
 Yeah, we use almost all 64 bits in config. I tried to describe the bitmaps
 in perf_event_p4.h (see Notes on internal configuration of ESCR+CCCR tuples).
 
 Guys, letme re-read this whole mail thread first since I have no clue
 what this remapping about ;)

If we need some special mark in config I can try to free hight bit in
@config and move it somehwere in low 32 bits (there are bits 28-29 which
i can use for that). Ie I can provide the sign bit, would it be enough?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Peter Zijlstra
On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:

 Guys, letme re-read this whole mail thread first since I have no clue
 what this remapping about ;)

x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
config values to mean -ENOENT and -EINVAL resp.

This means neither config value can be a 'real' event. Now it turns out
Xeon-Phi has an actual event 0, which is masked by these special case
thingies.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread stephane eranian
On Tue, Sep 25, 2012 at 2:01 PM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
 On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:

 Guys, letme re-read this whole mail thread first since I have no clue
 what this remapping about ;)

 x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
 config values to mean -ENOENT and -EINVAL resp.

 This means neither config value can be a 'real' event. Now it turns out
 Xeon-Phi has an actual event 0, which is masked by these special case
 thingies.

Then how about using -1 or -2 for ENOENT and EINVAL?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 02:05:58PM +0200, stephane eranian wrote:
 On Tue, Sep 25, 2012 at 2:01 PM, Peter Zijlstra a.p.zijls...@chello.nl 
 wrote:
  On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:
 
  Guys, letme re-read this whole mail thread first since I have no clue
  what this remapping about ;)
 
  x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
  config values to mean -ENOENT and -EINVAL resp.
 
  This means neither config value can be a 'real' event. Now it turns out
  Xeon-Phi has an actual event 0, which is masked by these special case
  thingies.
 
 Then how about using -1 or -2 for ENOENT and EINVAL?

-2 can't be a valid p4 config as far as i can tell.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 04:22:29PM +0400, Cyrill Gorcunov wrote:
 On Tue, Sep 25, 2012 at 02:05:58PM +0200, stephane eranian wrote:
  On Tue, Sep 25, 2012 at 2:01 PM, Peter Zijlstra a.p.zijls...@chello.nl 
  wrote:
   On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:
  
   Guys, letme re-read this whole mail thread first since I have no clue
   what this remapping about ;)
  
   x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
   config values to mean -ENOENT and -EINVAL resp.
  
   This means neither config value can be a 'real' event. Now it turns out
   Xeon-Phi has an actual event 0, which is masked by these special case
   thingies.
  
  Then how about using -1 or -2 for ENOENT and EINVAL?
 
 -2 can't be a valid p4 config as far as i can tell.

I mean such value can be easily recognized by p4 code and treated
specially if needed.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 02:01:26PM +0200, Peter Zijlstra wrote:
 On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:
 
  Guys, letme re-read this whole mail thread first since I have no clue
  what this remapping about ;)
 
 x86_setup_perfctr() / set_ext_hw_attr() have special purposed 0 and -1
 config values to mean -ENOENT and -EINVAL resp.
 
 This means neither config value can be a 'real' event. Now it turns out
 Xeon-Phi has an actual event 0, which is masked by these special case
 thingies.

So guys, if understand all things correctly it's supposed to use some
-1/-2 as initial @config value for unsupported events, right? Vince,
may not it be easier to use bit 19 as a flag of valid event and clear
it when you write to msr, thus we will not have to change zero is reserved
semantics (otoh i'm not sure if it won't become a problem somewhere in
future with some new cpu :)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Vince Weaver

On Tue, 25 Sep 2012, Cyrill Gorcunov wrote:

 So guys, if understand all things correctly it's supposed to use some
 -1/-2 as initial @config value for unsupported events, right? Vince,
 may not it be easier to use bit 19 as a flag of valid event and clear
 it when you write to msr, thus we will not have to change zero is reserved
 semantics (otoh i'm not sure if it won't become a problem somewhere in
 future with some new cpu :)

Well, we wouldn't want to use a reserved bit.
In theory we could re-use bit 22 (enable) or bit 20 (APIC enable)
because those values should in theory be set elsewhere and could probably
be masked out at an appropriate place.

Is -2 really a valid cache event on Pentium 4?

Though I admit patching all of the various PMU drivers to use -1/-2 rather 
than 0/-1 will be a pain, especially as many of them just default to 0
with no initialization currently. 

Vince Weaver
vincent.wea...@maine.edu
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2012 at 10:45:02AM -0400, Vince Weaver wrote:
 
 On Tue, 25 Sep 2012, Cyrill Gorcunov wrote:
 
  So guys, if understand all things correctly it's supposed to use some
  -1/-2 as initial @config value for unsupported events, right? Vince,
  may not it be easier to use bit 19 as a flag of valid event and clear
  it when you write to msr, thus we will not have to change zero is reserved
  semantics (otoh i'm not sure if it won't become a problem somewhere in
  future with some new cpu :)
 
 Well, we wouldn't want to use a reserved bit.
 In theory we could re-use bit 22 (enable) or bit 20 (APIC enable)
 because those values should in theory be set elsewhere and could probably
 be masked out at an appropriate place.
 
 Is -2 really a valid cache event on Pentium 4?

Nope, there can't be config with -2 as valid value. So we can use -2
if needed as far as I can tell (the -1 can't be valid as well).

 Though I admit patching all of the various PMU drivers to use -1/-2 rather 
 than 0/-1 will be a pain, especially as many of them just default to 0
 with no initialization currently.

Yup, but if it'll be needed I can tune up p4 code (thought i'll need
some help in testing since i've no p4 cpu anymore).
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-24 Thread Meadows, Lawrence F
There was a hack in my patch to workaround the event code 0 problem-- did you 
not get that? Anyway I'll compare this one to mine. I just got back from 
vacation so bear with me.

-Original Message-
From: Vince Weaver [mailto:vincent.wea...@maine.edu] 
Sent: Thursday, September 20, 2012 10:03 AM
To: linux-kernel@vger.kernel.org
Cc: Peter Zijlstra; Paul Mackerras; Ingo Molnar; Arnaldo Carvalho de Melo; 
eran...@gmail.com; Meadows, Lawrence F
Subject: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

Hello

Included below is a patch that adds perf support for the Xeon-Phi PMU, as 
documented in the "Intel Xeon Phi Coprocessor (codename: Knights
Corner) Performance Monitoring Units" manual.

Even though it is a co-processor, a Phi runs a full Linux environment and can 
support performance counters.

This is just barebones support, it does not add support for interesting new 
features such as the SPFLT intruction that allows starting/stopping events 
without entering the kernel.

The PMU internally is just like that of an original Pentium, but a P6-like MSR 
interface is provided.  The interface is different enough from a real P6 that 
it's not easy (or practical) to re-use the code in perf_event_p6.c

One additional complication:  some of the cache events map to event "0".  This 
causes problems because the generic events code assumes "0" means 
not-available.  I'm not sure the best way to address that problem.

Vince
vincent.wea...@maine.edu



diff -Nur linux-3.6-rc6/arch/x86/include/asm/msr-index.h 
linux-3.6-rc6-mic/arch/x86/include/asm/msr-index.h
--- linux-3.6-rc6/arch/x86/include/asm/msr-index.h  2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/include/asm/msr-index.h  2012-09-20 
11:55:14.854332191 -0400
@@ -121,6 +121,11 @@
 #define MSR_P6_EVNTSEL00x0186
 #define MSR_P6_EVNTSEL10x0187
 
+#define MSR_PHI_PERFCTR0   0x0020
+#define MSR_PHI_PERFCTR1   0x0021
+#define MSR_PHI_EVNTSEL0   0x0028
+#define MSR_PHI_EVNTSEL1   0x0029
+
 /* AMD64 MSRs. Not complete. See the architecture manual for a more
complete list. */
 
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/Makefile 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/Makefile
--- linux-3.6-rc6/arch/x86/kernel/cpu/Makefile  2012-09-16 17:58:51.0 
-0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/Makefile  2012-09-20 
12:15:21.042331190 -0400
@@ -32,7 +32,7 @@
 
 ifdef CONFIG_PERF_EVENTS
 obj-$(CONFIG_CPU_SUP_AMD)  += perf_event_amd.o
-obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_p4.o
+obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_phi.o 
perf_event_p4.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_lbr.o 
perf_event_intel_ds.o perf_event_intel.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_uncore.o
 endif
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perfctr-watchdog.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perfctr-watchdog.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perfctr-watchdog.c2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perfctr-watchdog.c2012-09-20 
11:56:51.430332108 -0400
@@ -56,6 +56,8 @@
switch (boot_cpu_data.x86) {
case 6:
return msr - MSR_P6_PERFCTR0;
+   case 11:
+   return msr - MSR_PHI_PERFCTR0;
case 15:
return msr - MSR_P4_BPU_PERFCTR0;
}
@@ -82,6 +84,8 @@
switch (boot_cpu_data.x86) {
case 6:
return msr - MSR_P6_EVNTSEL0;
+   case 11:
+   return msr - MSR_PHI_EVNTSEL0;
case 15:
return msr - MSR_P4_BSU_ESCR0;
}
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perf_event.h 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event.h
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event.h  2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event.h  2012-09-20 
12:49:25.782329486 -0400
@@ -624,6 +624,8 @@
 
 int p6_pmu_init(void);
 
+int phi_pmu_init(void);
+
 #else /* CONFIG_CPU_SUP_INTEL */
 
 static inline void reserve_ds_buffers(void) diff -Nur 
linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_intel.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_intel.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_intel.c2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_intel.c2012-09-20 
12:14:37.082331232 -0400
@@ -1906,6 +1906,8 @@
switch (boot_cpu_data.x86) {
case 0x6:
return p6_pmu_init();
+   case 0xb:
+   return phi_pmu_init();
case 0xf:
return p4_pmu_init(

RE: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-24 Thread Meadows, Lawrence F
There was a hack in my patch to workaround the event code 0 problem-- did you 
not get that? Anyway I'll compare this one to mine. I just got back from 
vacation so bear with me.

-Original Message-
From: Vince Weaver [mailto:vincent.wea...@maine.edu] 
Sent: Thursday, September 20, 2012 10:03 AM
To: linux-kernel@vger.kernel.org
Cc: Peter Zijlstra; Paul Mackerras; Ingo Molnar; Arnaldo Carvalho de Melo; 
eran...@gmail.com; Meadows, Lawrence F
Subject: [PATCH 1/1] perf, Add support for Xeon-Phi PMU

Hello

Included below is a patch that adds perf support for the Xeon-Phi PMU, as 
documented in the Intel Xeon Phi Coprocessor (codename: Knights
Corner) Performance Monitoring Units manual.

Even though it is a co-processor, a Phi runs a full Linux environment and can 
support performance counters.

This is just barebones support, it does not add support for interesting new 
features such as the SPFLT intruction that allows starting/stopping events 
without entering the kernel.

The PMU internally is just like that of an original Pentium, but a P6-like MSR 
interface is provided.  The interface is different enough from a real P6 that 
it's not easy (or practical) to re-use the code in perf_event_p6.c

One additional complication:  some of the cache events map to event 0.  This 
causes problems because the generic events code assumes 0 means 
not-available.  I'm not sure the best way to address that problem.

Vince
vincent.wea...@maine.edu



diff -Nur linux-3.6-rc6/arch/x86/include/asm/msr-index.h 
linux-3.6-rc6-mic/arch/x86/include/asm/msr-index.h
--- linux-3.6-rc6/arch/x86/include/asm/msr-index.h  2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/include/asm/msr-index.h  2012-09-20 
11:55:14.854332191 -0400
@@ -121,6 +121,11 @@
 #define MSR_P6_EVNTSEL00x0186
 #define MSR_P6_EVNTSEL10x0187
 
+#define MSR_PHI_PERFCTR0   0x0020
+#define MSR_PHI_PERFCTR1   0x0021
+#define MSR_PHI_EVNTSEL0   0x0028
+#define MSR_PHI_EVNTSEL1   0x0029
+
 /* AMD64 MSRs. Not complete. See the architecture manual for a more
complete list. */
 
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/Makefile 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/Makefile
--- linux-3.6-rc6/arch/x86/kernel/cpu/Makefile  2012-09-16 17:58:51.0 
-0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/Makefile  2012-09-20 
12:15:21.042331190 -0400
@@ -32,7 +32,7 @@
 
 ifdef CONFIG_PERF_EVENTS
 obj-$(CONFIG_CPU_SUP_AMD)  += perf_event_amd.o
-obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_p4.o
+obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_phi.o 
perf_event_p4.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_lbr.o 
perf_event_intel_ds.o perf_event_intel.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_uncore.o
 endif
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perfctr-watchdog.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perfctr-watchdog.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perfctr-watchdog.c2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perfctr-watchdog.c2012-09-20 
11:56:51.430332108 -0400
@@ -56,6 +56,8 @@
switch (boot_cpu_data.x86) {
case 6:
return msr - MSR_P6_PERFCTR0;
+   case 11:
+   return msr - MSR_PHI_PERFCTR0;
case 15:
return msr - MSR_P4_BPU_PERFCTR0;
}
@@ -82,6 +84,8 @@
switch (boot_cpu_data.x86) {
case 6:
return msr - MSR_P6_EVNTSEL0;
+   case 11:
+   return msr - MSR_PHI_EVNTSEL0;
case 15:
return msr - MSR_P4_BSU_ESCR0;
}
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perf_event.h 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event.h
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event.h  2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event.h  2012-09-20 
12:49:25.782329486 -0400
@@ -624,6 +624,8 @@
 
 int p6_pmu_init(void);
 
+int phi_pmu_init(void);
+
 #else /* CONFIG_CPU_SUP_INTEL */
 
 static inline void reserve_ds_buffers(void) diff -Nur 
linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_intel.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_intel.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_intel.c2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_intel.c2012-09-20 
12:14:37.082331232 -0400
@@ -1906,6 +1906,8 @@
switch (boot_cpu_data.x86) {
case 0x6:
return p6_pmu_init();
+   case 0xb:
+   return phi_pmu_init();
case 0xf:
return p4_pmu_init();
}
diff -Nur linux

[PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-20 Thread Vince Weaver
Hello

Included below is a patch that adds perf support for the Xeon-Phi PMU,
as documented in the "Intel Xeon Phi Coprocessor (codename: Knights 
Corner) Performance Monitoring Units" manual.

Even though it is a co-processor, a Phi runs a full Linux environment
and can support performance counters.

This is just barebones support, it does not add support for
interesting new features such as the SPFLT intruction that
allows starting/stopping events without entering the kernel.

The PMU internally is just like that of an original Pentium, but 
a P6-like MSR interface is provided.  The interface is different enough
from a real P6 that it's not easy (or practical) to re-use the code in 
perf_event_p6.c

One additional complication:  some of the cache events map to 
event "0".  This causes problems because the generic events code
assumes "0" means not-available.  I'm not sure the best way to address
that problem.

Vince
vincent.wea...@maine.edu



diff -Nur linux-3.6-rc6/arch/x86/include/asm/msr-index.h 
linux-3.6-rc6-mic/arch/x86/include/asm/msr-index.h
--- linux-3.6-rc6/arch/x86/include/asm/msr-index.h  2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/include/asm/msr-index.h  2012-09-20 
11:55:14.854332191 -0400
@@ -121,6 +121,11 @@
 #define MSR_P6_EVNTSEL00x0186
 #define MSR_P6_EVNTSEL10x0187
 
+#define MSR_PHI_PERFCTR0   0x0020
+#define MSR_PHI_PERFCTR1   0x0021
+#define MSR_PHI_EVNTSEL0   0x0028
+#define MSR_PHI_EVNTSEL1   0x0029
+
 /* AMD64 MSRs. Not complete. See the architecture manual for a more
complete list. */
 
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/Makefile 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/Makefile
--- linux-3.6-rc6/arch/x86/kernel/cpu/Makefile  2012-09-16 17:58:51.0 
-0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/Makefile  2012-09-20 
12:15:21.042331190 -0400
@@ -32,7 +32,7 @@
 
 ifdef CONFIG_PERF_EVENTS
 obj-$(CONFIG_CPU_SUP_AMD)  += perf_event_amd.o
-obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_p4.o
+obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_phi.o 
perf_event_p4.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_lbr.o 
perf_event_intel_ds.o perf_event_intel.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_uncore.o
 endif
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perfctr-watchdog.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perfctr-watchdog.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perfctr-watchdog.c2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perfctr-watchdog.c2012-09-20 
11:56:51.430332108 -0400
@@ -56,6 +56,8 @@
switch (boot_cpu_data.x86) {
case 6:
return msr - MSR_P6_PERFCTR0;
+   case 11:
+   return msr - MSR_PHI_PERFCTR0;
case 15:
return msr - MSR_P4_BPU_PERFCTR0;
}
@@ -82,6 +84,8 @@
switch (boot_cpu_data.x86) {
case 6:
return msr - MSR_P6_EVNTSEL0;
+   case 11:
+   return msr - MSR_PHI_EVNTSEL0;
case 15:
return msr - MSR_P4_BSU_ESCR0;
}
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perf_event.h 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event.h
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event.h  2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event.h  2012-09-20 
12:49:25.782329486 -0400
@@ -624,6 +624,8 @@
 
 int p6_pmu_init(void);
 
+int phi_pmu_init(void);
+
 #else /* CONFIG_CPU_SUP_INTEL */
 
 static inline void reserve_ds_buffers(void)
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_intel.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_intel.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_intel.c2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_intel.c2012-09-20 
12:14:37.082331232 -0400
@@ -1906,6 +1906,8 @@
switch (boot_cpu_data.x86) {
case 0x6:
return p6_pmu_init();
+   case 0xb:
+   return phi_pmu_init();
case 0xf:
return p4_pmu_init();
}
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_phi.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_phi.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_phi.c  1969-12-31 
19:00:00.0 -0500
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_phi.c  2012-09-20 
12:48:28.454329539 -0400
@@ -0,0 +1,236 @@
+#include 
+#include 
+
+#include "perf_event.h"
+
+static const u64 phi_perfmon_event_map[] =
+{
+  [PERF_COUNT_HW_CPU_CYCLES]   = 0x002a,
+  [PERF_COUNT_HW_INSTRUCTIONS] = 0x0016,

[PATCH 1/1] perf, Add support for Xeon-Phi PMU

2012-09-20 Thread Vince Weaver
Hello

Included below is a patch that adds perf support for the Xeon-Phi PMU,
as documented in the Intel Xeon Phi Coprocessor (codename: Knights 
Corner) Performance Monitoring Units manual.

Even though it is a co-processor, a Phi runs a full Linux environment
and can support performance counters.

This is just barebones support, it does not add support for
interesting new features such as the SPFLT intruction that
allows starting/stopping events without entering the kernel.

The PMU internally is just like that of an original Pentium, but 
a P6-like MSR interface is provided.  The interface is different enough
from a real P6 that it's not easy (or practical) to re-use the code in 
perf_event_p6.c

One additional complication:  some of the cache events map to 
event 0.  This causes problems because the generic events code
assumes 0 means not-available.  I'm not sure the best way to address
that problem.

Vince
vincent.wea...@maine.edu



diff -Nur linux-3.6-rc6/arch/x86/include/asm/msr-index.h 
linux-3.6-rc6-mic/arch/x86/include/asm/msr-index.h
--- linux-3.6-rc6/arch/x86/include/asm/msr-index.h  2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/include/asm/msr-index.h  2012-09-20 
11:55:14.854332191 -0400
@@ -121,6 +121,11 @@
 #define MSR_P6_EVNTSEL00x0186
 #define MSR_P6_EVNTSEL10x0187
 
+#define MSR_PHI_PERFCTR0   0x0020
+#define MSR_PHI_PERFCTR1   0x0021
+#define MSR_PHI_EVNTSEL0   0x0028
+#define MSR_PHI_EVNTSEL1   0x0029
+
 /* AMD64 MSRs. Not complete. See the architecture manual for a more
complete list. */
 
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/Makefile 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/Makefile
--- linux-3.6-rc6/arch/x86/kernel/cpu/Makefile  2012-09-16 17:58:51.0 
-0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/Makefile  2012-09-20 
12:15:21.042331190 -0400
@@ -32,7 +32,7 @@
 
 ifdef CONFIG_PERF_EVENTS
 obj-$(CONFIG_CPU_SUP_AMD)  += perf_event_amd.o
-obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_p4.o
+obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_phi.o 
perf_event_p4.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_lbr.o 
perf_event_intel_ds.o perf_event_intel.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_uncore.o
 endif
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perfctr-watchdog.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perfctr-watchdog.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perfctr-watchdog.c2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perfctr-watchdog.c2012-09-20 
11:56:51.430332108 -0400
@@ -56,6 +56,8 @@
switch (boot_cpu_data.x86) {
case 6:
return msr - MSR_P6_PERFCTR0;
+   case 11:
+   return msr - MSR_PHI_PERFCTR0;
case 15:
return msr - MSR_P4_BPU_PERFCTR0;
}
@@ -82,6 +84,8 @@
switch (boot_cpu_data.x86) {
case 6:
return msr - MSR_P6_EVNTSEL0;
+   case 11:
+   return msr - MSR_PHI_EVNTSEL0;
case 15:
return msr - MSR_P4_BSU_ESCR0;
}
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perf_event.h 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event.h
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event.h  2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event.h  2012-09-20 
12:49:25.782329486 -0400
@@ -624,6 +624,8 @@
 
 int p6_pmu_init(void);
 
+int phi_pmu_init(void);
+
 #else /* CONFIG_CPU_SUP_INTEL */
 
 static inline void reserve_ds_buffers(void)
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_intel.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_intel.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_intel.c2012-09-16 
17:58:51.0 -0400
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_intel.c2012-09-20 
12:14:37.082331232 -0400
@@ -1906,6 +1906,8 @@
switch (boot_cpu_data.x86) {
case 0x6:
return p6_pmu_init();
+   case 0xb:
+   return phi_pmu_init();
case 0xf:
return p4_pmu_init();
}
diff -Nur linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_phi.c 
linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_phi.c
--- linux-3.6-rc6/arch/x86/kernel/cpu/perf_event_phi.c  1969-12-31 
19:00:00.0 -0500
+++ linux-3.6-rc6-mic/arch/x86/kernel/cpu/perf_event_phi.c  2012-09-20 
12:48:28.454329539 -0400
@@ -0,0 +1,236 @@
+#include linux/perf_event.h
+#include linux/types.h
+
+#include perf_event.h
+
+static const u64 phi_perfmon_event_map[] =
+{
+  [PERF_COUNT_HW_CPU_CYCLES]   = 0x002a,
+