If schedule() uses lazy interrupt disabling, the problem we are seeing 
could result, since the PMU interrupt does not use the lazy interrupt 
wrapper on POWER.

Do you think that using the pfm irq versions of this code is too much of 
a performance hit?

I don't see any way for this to work right on POWER without this change, 
short of changing the wrapper used for the PMU interrupt (which we've 
already decided was a bad idea).  Of course we could ifdef this code for 
POWER, I suppose.  Ick.

In any case, the fix in perfmon_smpl.c needs to be fixed, right?  The 
other unlock in that function is a pfm_spin_unlock_irqrestore(...)

- Corey

> 
> The reason regular spin_lock/spin_unlock are used is because the
> __pfm_ctxsw() routine is expected to
> be run with interrupts ALREADY masked by upper level code (likely
> schedule()).  It may be that on PPC,
> schedule does things differently at its tail (where switch_to()) is invoked.
> 
> You are trying adding a BUG_ON(!irqs_disabled()) and see if you catch
> something. If not then I wonder
> how this could be related to the lazy masking for which you had to add
> the special pfm_spin_lock_irq.....
> 

-- 
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
perfmon2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to