Corey, I ran a few tests. It appears that on both X87 (Core 2) and Itanium 2 (Montvale) there is a 4% penalty on average PMU ctxsw cost by using interrupt masking. That is a bit high. So instead, I have provided macros for you to override just like what you did for spin_lock_irqsave and pfm_spin_unlock_irqrestore(). Try overriding them on PPC and let me know if this works now. Just pull from GIT to get the patch.
On Thu, Apr 10, 2008 at 2:20 AM, Corey J Ashford <[EMAIL PROTECTED]> wrote: > > > Hi Stephane, > > Thanks for the replies. > > I didn't check with Paul, but I looked into the code in schedule() and it > does call local_irq_disable(), which does use the soft interrupt disabling > mechanism. > > - Corey > > > Corey Ashford > Software Engineer > IBM Linux Technology Center, Linux Toolchain > Beaverton, OR > 503-578-3507 > [EMAIL PROTECTED] > > > "stephane eranian" <[EMAIL PROTECTED]> wrote on 04/09/2008 03:46:56 > PM: > > > > > Corey, > > > > > > On Thu, Apr 10, 2008 at 12:26 AM, Corey Ashford <[EMAIL PROTECTED]> > wrote: > > > 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. > > > > > Could you confirm this with Paul? > > > > > Do you think that using the pfm irq versions of this code is too much > of a > > > performance hit? > > > > You would be masking interrupts which are already masked. I don't know > > the cost for each arch. > > > > > > > > > > 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. > > > > No, I'd rather pay the (hopefully) small penalty but have more readable > code. > > > > > > > > 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(...) > > > > > > > I don't think the change in perfmon_smpl.c is needed. There is a reason > why > > the unlock is broken down in multiple steps. We need to have > > interrupts enabled > > for vfree() in pfm_context_free(). pfm_spin_unlock_irqrestore() does > > not guarantee > > that interrupts will be enabled, it simply restores them to the state > > they were before > > spin_lock_irqsave(). I have seen situations (I think on IA-64) where > > pfm_handle_work > > is not invoked with interrupts enabled. This part of the code is > > handling a very special > > case where the context is zombie, i.e., no more controlling > > (monitoring) process. > > > > As for perfmon_intr.c, the reason this is regular spin_lock is because > > interrupts are already > > masked up to the same priority level. The PMU interrupts should be set > > very high in the > > priority levels. On X86, all interrupts are automatically masked. I > > think that we could > > enforce all interrupts masked with irqsave() to guarantee across the > > board that we have > > the same level of intr. masking. > > > > > > > > > - 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
