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

[Jeremy Kerr]

Christoph,

As far as I know, the only current use of NOSCHED contexts is isolated 
mode. Consequently, there may be some overlap between the two goals 
here, which is probably something we should sort out.

> 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.

>  (2) it selects a different set of files in the context directory
> 	- probably makes sense, it might be better to have a nosched
> 	  flag in the tree_descr to make sure they are kept in sync

Isn't the presence of the NOSCHED flag in the context enough? What needs 
to be kept 'in sync' ?

>  (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.

> What's lacking is any affect on scheduling.  What are the semantics
> SPU_CREATE_NOSCHED should have on scheduling?  We should probably
> avoid involuntary context switches.

Yep.

> 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...).

> Should we  ensure they get switched back to the same spu?

Definitely, if the context is ever switched out. But that shouldn't be 
happening.

Cheers,


Jeremy