[Cbe-oss-dev] [PATCH 3/6] spufs: fix starvation case with terminated spes

[Luke Browning]

On Wed, 2008-02-13 at 05:43 +0100, Arnd Bergmann wrote:
> On Wednesday 06 February 2008, Luke Browning wrote:
> > Fix spu starvation case with terminated ctxts.
> > 
> > Terminated spe contexts need to yield the spu, so that the spufs scheduler
> > can service the runqueue.  Can't rely on the libspe to destroy the context 
> > as it is not a trusted entity.  Fixes a testcase where a program creates 
> > 100 standalone contexts (ie. gang of one) and then waits for them to 
> > complete before it starts to destroy contexts. 
> > 
> > Moved spu_yield() into spu_run_fini() to avoid the extra lock reference. 
> > 
> > Signed-off-by: Luke Browning <lukebrowning at us.ibm.com>
> 
> I don't understand this patch, how is a context that returned 0x2000
> different from any other? Obviously, you'd want it to become descheduled
> also if it returns 0x2001 or any user-specific stop code that lets
> the context be idle for some time.
> 
> If we don't apply "force" in the __spu_deactivate(), shouldn't the context
> always become deactivated if there is any other context waiting to get
> scheduled?

I restricted it to termination as I didn't want to de-schedule the spu
context each time that a remote library call is made. Many remote
library calls don't block, so it is best to keep the context loaded as
as the PPE thread will soon return.  If we block it, then we will end up
with a bunch of extra context switches... 

Also, I am concerned that it might lead to problems in the gang
scheduling programming model where one spu interacts with another spu
within the same gang through a remote library call.  For example, if two
spus communicated with each other through a pipe, one reading and the
other writing, the gang would deadlock as the reader would prevent the
writer from running.  

Luke