[Cbe-oss-dev] spufs: problem in scheduler

[Arnd Bergmann]

Am Saturday 25 February 2006 00:53 schrieb Geoff Levand:
> At the time of unbinding, ctx->reap_work should be flushed
> from kernel's work queue I thought, but at this point the
> kernel has write lock of spu context(ctx->state_sem), and
> work job for spu reaper needs it too.  I think it may need
> fundamental restructuring to fix it, but I have no idea to
> do it well.

I think I saw the same problem before, when I tried to rework
the logic behind spu_acquire / spu_release. I made only
what I assumed to be equivalent transformations but kept
hitting this bug, so I stopped working on that patch.

> I don't understand the spu scheduler so well,  but it seems
> it may need to edit many lines of scheduler's code.  It may
> be good to ask Mark-san to fix it, since I heard he wrote it.

When Mark introduced the preemptive scheduling, some of the
previous assumptions about who owns an spu_context changed
fundamentally.
Originally, any long operation on a context would hold 
down_read(&ctx->state_sema) so the state can not change, but
now we always drop that lock before going to sleep, so the
mutex is never held for a significant amount of time.

This means we now have the complexity of abusing rw_semaphores
for our own strange context locking system as well as the
complexity of a lock-breaking sleep primitive (spufs_wait)
that is needed for the preemption work queue.

One way I could imagine us getting out of this problem
again would be to make at least spufs_run_spu hold the read
lock and instead of just preempting under the hood of it, we
wake up ctx->stop_wq and make spufs_run_spu give up the context
when another context wants to run on that spu.

If we don't do that, a first step might be to replace the
read/write semaphore in context.c with a simple mutex, since
the chance of ever needing multiple readers is so low that
I'd rather have less complex code there.

	Arnd <><