[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:

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

Sorry, I didn't understand that termination was not architected.  I
assumed that there was a special halt instruction that generated a
unique stop value that could be used.  I kept seeing 0x2000 because that
is what we commonly used and made a false assumption.

The problem is not with spu_yield() per se.  It is doing what you
described, but if there is no context on the runqueue it leaves the
current context loaded.  If this context has a high priority, it is not
preemptable by incoming work.  I chose to fix this problem by enhancing
spu_yield() to check for terminated contexts specifically.

I have another patch coming that is more generic.

Regards,
Luke