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.025 / U:270.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site