OProfile

At Thu, 26 Sep 2002 11:05:50 -0400,
Will Cohen wrote:

> I have been going through an looking at setup information for the P4. I 
> found that the TC_DELIVER_MODE was incorrect.

thanks, sorry.

> I also noticed that the event for GLOBAL_POWER_EVENTS is different from 
> the one listed in the appendix listing the events. There is a comment in 
> module/x86/op_model_p4.c that say comments there is a difference but no 
> reason why.

yes, I suppose I should have elaborated in the comment:

the manual says 0x05. if you put 0x05 in it does nothing. but if you
look at the brink / abyss code, in brink/pentium4_emon.txt, you will
find this little gem:

    <global_power_events>
        <event_select>0x13</event_select>
	...
    </global_power_events>

no other explanation given there, though. it works when you use
that. a couple times I had to read brink or perfctr to discover p4
quirks. hooray for free software :)

-graydon

Could we get this correction into the oprofile CVS? It is a trivial 
correction. -Will

Will Cohen wrote:
> I have been going through an looking at setup information for the P4. I 
> found that the TC_DELIVER_MODE was incorrect.
> 
> 2002-09-26  Will Cohen  <wcohen@...>
> 
>     * module/x86/op_model_p4.c: Correct TC_DELIVER_MODE cccr select.
> 
> I also noticed that the event for GLOBAL_POWER_EVENTS is different from 
> the one listed in the appendix listing the events. There is a comment in 
> module/x86/op_model_p4.c that say comments there is a difference but no 
> reason why.
> 
> -Will
> 
> 
> ------------------------------------------------------------------------
> 
> --- oprofile/module/x86/op_model_p4.c	Wed Sep 25 10:46:47 2002
> +++ oprofile-build.20020925/module/x86/op_model_p4.c	Thu Sep 26 13:38:03 2002
> @@ -74,7 +74,7 @@
>  	},
>  	
>  	{ /* TC_DELIVER_MODE */
> -		0x04, 0x01,
> +		0x01, 0x01,
>  		{ { CTR_MS_0, MSR_P4_TC_ESCR0},  
>  		  { CTR_MS_2, MSR_P4_TC_ESCR1} }
>  	},

On Mon, Sep 30, 2002 at 05:43:28PM -0400, William Cohen wrote:

> Could we get this correction into the oprofile CVS? It is a trivial 
> correction. -Will

OK, applied. Sorry for the delay.

btw, what is the status of hyperthreading and P4 ? I'd still like to do
a release fairly soon.

regards
john

-- 
"When your name is Winner, that's it. You don't need a nickname."
	- Loser Lane

OProfile didn't die horribly on the P4 HT machine, but the current P4 
performance monitoring support doesn't deal with the complexities of the 
hyperthreading (assigning counter overflow samples to the correct 
thread). I will get a cputype check to determine whether the 
hyperthreading is active Tuesday.

-Will

John Levon wrote:
> On Mon, Sep 30, 2002 at 05:43:28PM -0400, William Cohen wrote:
> 
> 
>>Could we get this correction into the oprofile CVS? It is a trivial 
>>correction. -Will
> 
> 
> OK, applied. Sorry for the delay.
> 
> btw, what is the status of hyperthreading and P4 ? I'd still like to do
> a release fairly soon.
> 
> regards
> john
>

Here is my first pass at testing to determine whether the p4 is running 
in HT and to avoid using the performance monitoring hardware if that is 
the case.  The code has been tried on non-HT and HT p4 processors.

2002-10-01  Will Cohen  <wcohen@...>

	* module/x86/cpu_type.c (p4_threads): New.
	  (get_cpu_type): Use p4_threads().
	* doc/oprofile.xml: Add comment about P4 HT support.

-Will

John Levon wrote:
> On Mon, Sep 30, 2002 at 05:43:28PM -0400, William Cohen wrote:
> 
> 
>>Could we get this correction into the oprofile CVS? It is a trivial 
>>correction. -Will
> 
> 
> OK, applied. Sorry for the delay.
> 
> btw, what is the status of hyperthreading and P4 ? I'd still like to do
> a release fairly soon.
> 
> regards
> john
>

On Tue, Oct 01, 2002 at 11:17:56AM -0400, William Cohen wrote:

> Here is my first pass at testing to determine whether the p4 is running 
> in HT and to avoid using the performance monitoring hardware if that is 
> the case.  The code has been tried on non-HT and HT p4 processors.

OK. What needs to be done to support HT ?

regards
john

The P4 HT duplicates the user register and some interrupt handling 
registers. Much of the hardware between the logical processors is 
shared, e.g. the performance monitoring hardware. This means that 
performance event setting on one logical processor will affect the event 
set on the other logical processor on the die. The code that sets up the 
perfmon hardware will need to realize that shared between pairs of 
processors.

Another significant problem is attributing the event sample to the 
correct thread. There are two basic classes of performance monitoring 
event on the P4: Thread Specific (TS) and Thread Independent (TI). For 
TS events a performance counter can be set to monitor one logical 
processor or the other (or both). For TI events, e.g. instruction 
decoding, counts from both threads are lumped together. This means for 
TI events that another thread can significantly affect the measurements.

I was hoping that we could dupicate the performance monitoring events in 
other half of the performance registers on the P4 and effectively 
monitor both logical threads. However, the way that the registers are 
set up this does not seem to be possible.

perfctr has similar problems with the P4 HT hardware.

-will



John Levon wrote:
> On Tue, Oct 01, 2002 at 11:17:56AM -0400, William Cohen wrote:
> 
> 
>>Here is my first pass at testing to determine whether the p4 is running 
>>in HT and to avoid using the performance monitoring hardware if that is 
>>the case.  The code has been tried on non-HT and HT p4 processors.
> 
> 
> OK. What needs to be done to support HT ?
> 
> regards
> john
>