Re: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile for profilingCell BE SPUs -- update

[Maynard Johnson]

Arnd Bergmann wrote:

> On Monday 29 January 2007 20:48, Maynard Johnson wrote:
>  
>
> > Subject: Add support to OProfile for profiling Cell BE SPUs
> >
> >    
>  
[snip]

> > + * 
> > + * Ideally, we would like to be able to create the cached_info for
> > + * an SPU task just one time -- when libspe first loads the SPU 
> > + * binary file.  We would store the cached_info in a list.  Then, as
> > + * SPU tasks are switched out and new ones switched in, the cached_info
> > + * for inactive tasks would be kept, and the active one would be placed
> > + * at the head of the list.  But this technique may not with
> > + * current spufs functionality since the spu used in bind_context may
> > + * be a different spu than was used in a previous bind_context for a
> > + * reactivated SPU task.  Additionally, a reactivated SPU task may be
> > + * assigned to run on a different physical SPE.  We will investigate
> > + * further if this can be done.
> > + *
> > + */
> >    
>
> You should stuff a pointer to cached_info into struct spu_context,
> e.g. 'void *profile_private'.
>  
I seem to recall looking at this option a while back, but didn't go that 
route since struct spu_context is opaque to me.  With such a teqnique, I 
could then use a simple 16-element array of  pointers to cached_info 
objects, creating them as needed when spu_context->profile_private is 
NULL.  I suppose the better option for now is to add a 
get_profile_private() function to SPUFs, rather than requiring 
spu_context to be visible.  Don't know why I didn't think to do that 
before.  Ah, well, live and learn.

-Maynard

>  
>
> > +struct cached_info {
> > +       vma_map_t * map;
> > +       struct spu * the_spu;
> > +       struct kref cache_ref;
> > +       struct list_head list;
> > +};
> >    
>
> And replace the 'the_spu' member with a back pointer to the
> spu_context if you need it.
>
>  
>
> 	Arnd <><
>  


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