[Cbe-oss-dev] [RFC] [PATCH 2:8] SPU Gang Scheduling - deactivation

[Arnd Bergmann]

On Tuesday 04 March 2008, Luke Browning wrote:
> I believe this is the right trade off.  If we required a context switch
> each time that a context returned to user mode, there would be a lot
> more context switches, system overhead would increase, and physical spu
> utilization would be lower - a lot lower.  We would, in effect, be
> maximizing the weakest part of the system - the PPUs.  
> 
> I think this would place a great burden on the application developer to
> fine tune his application to minimize the use of PPUs.  He would have to
> be a lot more careful about how he utilized gangs as certain instruction
> sequences would always cause the gang to be de-scheduled.  He couldn't
> just use gangs as way to improve the locality of shared data.  I think
> this would greatly limit the appeal of gangs.  

I was not suggesting to deschedule the gang when one of the contexts
becomes idle, quite the opposite. My point was that in order to minimize
the load on the PPU, we should try to do as little as possible on it,
meaning that in doubt we don't change what's currently running:

* If there is no other gang waiting to become scheduled, the currently
loaded one stays where it is (we've been doing this forever and I
don't think anyone is trying to change that).

* When some contexts in a gang become idle while others are still
executing code, the whole gang stays active until its time slice ends,
even if others are waiting. This is what you describe as well, and
I'm supporting this idea 100%.

* If a gang is currently running, and another gang has part of its
threads waiting to run, I *don't* want to schedule the new one, but
rather wait until all threads in the waiting gang actually want to
run. This is my main idea about what should be done different from
your approach.

* Finally, if there is only one gang that wants to run, but some of
its contexts are idle, we may potentially load that one anyway,
since it doesn't hurt much. However, I wouldn't bother too much about
making a special case for this one.

	Arnd <><