<html><body>
<p><tt>maynardj@linux.vnet.ibm.com wrote on 08/12/2006 01:04:30 PM:<br>
<br>
> Arnd Bergmann wrote:<br>
> <br>
> >On Wednesday 06 December 2006 23:04, Maynard Johnson wrote:<br>
> > <br>
> >No code should ever need to look at other SPUs when performing an<br>
> >operation on a given SPU, so we don't need to hold a global lock<br>
> >during normal operation.<br>
> ><br>
> >We have two cases that need to be handled:<br>
> ><br>
> >- on each context unload and load (both for a full switch operation),<br>
> > call to the profiling code with a pointer to the current context<br>
> > and spu (context is NULL when unloading).<br>
> ><br>
> > If the new context is not know yet, scan its overlay table (expensive)<br>
> > and store information about it in an oprofile private object. Otherwise<br>
> > just point to the currently active object, this should be really cheap.<br>
> ><br>
> >- When enabling oprofile initially, scan all contexts that are currently<br>
> > running on one of the SPUs. This is also expensive, but should happen<br>
> > before the measurement starts so it does not impact the resulting data.<br>
> ><br>
</tt><br>
<tt>Agreed. </tt><br>
<br>
<tt><snip></tt><br>
<br>
<tt>> >>I'm not exactly sure what you're saying here. Are you suggesting that a <br>
> >>user may only be interested in acitve SPU notification and, therefore, <br>
> >>shouldn't have to be depenent on the "standard" notification <br>
> >>registration succeeding? There may be a case for adding a new <br>
> >>registration function, I suppose; although, I'm not aware of any other <br>
> >>users of the SPUFS notification mechanism besides OProfile and PDT, and <br>
> >>we need notification of both active and future SPU tasks. But I would <br>
> >>not object to a new function.<br>
> >><br>
> >> <br>
> >><br>
> >I think what Luke was trying to get to is that notify_spus_active() should<br>
> >not call blocking_notifier_call_chain(), since it will notify other users<br>
> >as well as the newly registered one. Instead, it can simply call the<br>
> >notifier function directly.<br>
> > <br>
> ><br>
> Ah, yes. Thanks to both of you for pointing that out. I'll fix that <br>
> and re-post.<br>
> <br>
> -Maynard<br>
> <br>
</tt><br>
<tt>I actually was hoping to take this one step further. If the interface to</tt><br>
<tt>the context switch handler is something like:</tt><br>
<br>
<tt>switch_handler(int spu_id, from_ctx, to_ctx)</tt><br>
<br>
<tt>The kernel extension can maintain an internal spu table of its own where it</tt><br>
<tt>marks the named spuid as active or not. You don't need to have a bunch of</tt><br>
<tt>individual calls. Internally, you can keep track of it yourself.</tt><br>
<br>
<tt>Luke</tt></body></html>