[Cbe-oss-dev] [PATCH 2/2] spu sched: static timeslicing for SCHED_RR contexts

[Benjamin Herrenschmidt]

> Having a single workqueue like this is _probably_ enough,
> but I wonder if we get better behaviour by using per numa
> node work queues. Maybe someone from our performance
> team wants to analyse this.

How bad is the limitation of only running the SPU scheduler at task
level ?

Among other things, I've been thinking about the typical usage scenarios
of in-kernel SPEs. While I want them to use normal SPU contexts, one of
the thing that typically come to mind is the ability to fire them off at
interrupt time. It would be annoying to take the latency of queuing a
workqueue especially if the context happens to already be present on an
SPU which then ony needs to be "run" (hasn't been replaced by something
else). Something like a SPURS job model.

One of the thing that comes to mind right away to allow that sort of
optimisation is to have a spinlock rather than a mutex to protext the
SPU scheduler run queue.

Ben.