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

[Arnd Bergmann]

On Wednesday 13 February 2008, Luke Browning wrote:
> 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... 

I don't think we can live with those semantics, a library call most
certainly has to be a schedule point. It's different for system calls
in the kernel, for which we can detect wether or not the thread actually
sleeps.

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

If they are part of the same gang, there is no problem, as the gang
scheduling semantics require a lazy unload, where we only deschedule
the gang when _all_ the threads have gone to sleep or the time slice
ends.

Even if they are part of different gangs that you can't have running
simulteously, I don't see how it would deadlock, as the pipe reader
and writer don't need to run at the same time in order to access
the pipe buffer. It will be rather inefficient to do that, but that
is the documented behavior of gang scheduling.

	Arnd <><