[Cbe-oss-dev] [PATCH 2/2] spufs: Remove spurious WARN_ON for spu_deactivate for NOSCHED contexts

[Jeremy Kerr]

Arnd,

Some thoughts:

> That's different. If you only want to have the process occupy the
> physical SPU, you can just give it the highest real-time priority
> and will still be able to debug it.
> Also, you can always use regular scheduleable threads during
> development and only switch on the NOSCHED flag for production use.

But that's artifact of the undebugability of NOSCHED contexts - it'd be 
better to have as little difference as possible, right? Any difference 
between development and production is an extra hurdle for deployment & 
testing.

ie, NOSCHED should mean exactly that - the context isn't affected by the 
scheduler. That's all.

So we could do something where a NOSCHED context can still be 
spu_acquire_saved(), but the physical SPE stays reserved for that 
context. If a context *is* ever swapped out (e.g. by accessing the regs 
file), it'll always end up back on the same physical SPE.

This way, a NOSCHED thread is never taken off a SPE, unless the user 
requests it.

> It was introduced for isolated  tasks, which simply break if you try
> to read the registers. 

Then we make the register accesses conditional on !ISOLATE, rather 
than !NOSCHED.

> Another case where you want to use NOSCHED threads is maintaining the
> association between the context and a physical SPU for performance
> reasons: Some programs store data structures in the local store
> memory of another SPU. Once you allow it to be accessed by the
> debugger, you not only break the real-time behaviour of that thread,
> but also of all threads trying to use its data structures.

Sure, real-time goes out the window when you start blocking at arbitrary 
points.

I think this is related to the "mechanism vs policy" argument - we can 
provide the mechanism for debugging NOSCHED contexts. If a user wants 
to shoot themselves in the foot by messing up the real-time behaviour 
of their program, then they can. But for the cases where there's no 
technical problem doing this, then there's no need for the kernel to be 
preventing it.

However, the main problem is that we'd need to implement the reservation 
scheme - and that requires time :D


Jeremy