[Cbe-oss-dev] what's the expected behaviour for nosched contexts?

[Christoph Hellwig]

On Fri, Jun 01, 2007 at 10:32:35AM +1000, Jeremy Kerr wrote:
> > Currenly SPU_CREATE_NOSCHED has the following affects on spu
> > contexts:
> >
> >  (1) they're excluded from coredumps
> > 	- why?
> 
> I assume this comes from the isolated concept, rather than schedling.

Ok, I'll change this to check for the isolated flag instead.

> >  (3) creating requires CAP_SYS_NICE
> >  	- makes sense
> >
> >  (4) we do some accouting for the number of nosched spus, and
> >      we ignore them when making affinity placement decisions
> 
> I believe this is more a placeholder for future stuff. Andre?
> 
> I vaguely recall that we were talking about removing this accounting a 
> few months ago.

This is for the affinity code and makes sense when we really never
switch out the nosched contexts.

> > What about voluntary context  switches, e.g. for spu_acquire_saved? 
> > Are they allowed?
> 
> I would say no. The files under contexts that cause a spu_acquire_saved 
> are not present in the nosched_contents (although I see that a 
> signal{1,2} read will cause this, patch coming...).

Ok, I'll put a check into spu_acquire_saved to error out and printk
if it's ever called on a NOSCHED context.  We'll also want a similar
check for spu_yield.