lkml.org 
[lkml]   [2006]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Cbe-oss-dev] [PATCH]Add notification for active Cell SPU tasks
Luke Browning wrote:
> maynardj@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 function prototype for the switch handler is set in concrete by the
notification framework. The parameters are: struct notifier_block *,
unsigned long, void *.
>
> 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.
I think this would be nice to have, and I will look into it as I have
time. However, for the existing usage of the SPU switch notification, I
don't think it's too critical, since most users are not going to be
trying to do profiling or debugging with multiple SPU apps running
simultaneously.
>
> Luke
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-12-12 15:51    [W:0.026 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site