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

[Arnd Bergmann]

On Tuesday 17 July 2007, Michael Ellerman wrote:
> 
> > IIRC, time we discussed this the conclusion was that NOSCHED tasks
> > should not dump core, as that just creates extra special cases
> > and you can't debug them anyway.
> 
> That's the point. You _should_ be able to dump them and you _should_ be
> able to debug them. If I nice(1) a process it doesn't all of a sudden
> become undebuggable.

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.

NOSCHED SPU threads are for the special case that you can't have the
SPU leave the physical SPU, ever. It was introduced for isolated tasks,
which simply break if you try to read the registers.
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. Worse, when it comes back there is no guarantee
on which physical SPU the context will be restored, so any program that
is fine-tuned to the relative location of SPUs breaks.

	Arnd <><