[Cbe-oss-dev] [PATCH]Add notification for active Cell SPU tasks

[Luke Browning]

maynardj at linux.vnet.ibm.com wrote on 08/12/2006 01:04:30 PM:

> Arnd Bergmann wrote:
>
> >On Wednesday 06 December 2006 23:04, Maynard Johnson wrote:
> >
> >No code should ever need to look at other SPUs when performing an
> >operation on a given SPU, so we don't need to hold a global lock
> >during normal operation.
> >
> >We have two cases that need to be handled:
> >
> >- on each context unload and load (both for a full switch operation),
> >  call to the profiling code with a pointer to the current context
> >  and spu (context is NULL when unloading).
> >
> >  If the new context is not know yet, scan its overlay table (expensive)
> >  and store information about it in an oprofile private object.
Otherwise
> >  just point to the currently active object, this should be really
cheap.
> >
> >- When enabling oprofile initially, scan all contexts that are currently
> >  running on one of the SPUs. This is also expensive, but should happen
> >  before the measurement starts so it does not impact the resulting
data.
> >

Agreed.

<snip>

> >>I'm not exactly sure what you're saying here.  Are you suggesting that
a
> >>user may only be interested in acitve SPU notification and, therefore,
> >>shouldn't have to be depenent on the "standard" notification
> >>registration succeeding?  There may be a case for adding a new
> >>registration function, I suppose; although, I'm not aware of any other
> >>users of the SPUFS notification mechanism besides OProfile and PDT, and

> >>we need notification of both active and future SPU tasks.  But I would
> >>not object to a new function.
> >>
> >>
> >>
> >I think what Luke was trying to get to is that notify_spus_active()
should
> >not call blocking_notifier_call_chain(), since it will notify other
users
> >as well as the newly registered one. Instead, it can simply call the
> >notifier function directly.
> >
> >
> Ah, yes.  Thanks to both of you for pointing that out.  I'll fix that
> and re-post.
>
> -Maynard
>

I actually was hoping to take this one step further.  If the interface to
the context switch handler is something like:

switch_handler(int spu_id, from_ctx, to_ctx)

The kernel extension can maintain an internal spu table of its own where it
marks the named spuid as active or not.  You don't need to have a bunch of
individual calls.  Internally, you can keep track of it yourself.

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20061208/9ada39bc/attachment.htm>