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

[Jeremy Kerr]

Arnd,

> But that would be doing the opposite of what we created the NOSCHED
> flag for in the first place. The idea was to minimize the difference
> between an ISOLATE thread and a regular one running without the
> ISOLATE flag, but splitting the isolation into the NOSCHED property,
> which makes the kernel behave differently regarding scheduling and
> debuggability, and the actual ISOLATE flag that only changes how
> the hardware acts and how it interfaces to the kernel.

Does this actually gain us anything? we already have a lot of other 
differences between NOSCHED and ISOLATE:

* different binary format
* different loading procedure
* slightly different PPE library call interface
* no access to local store
* no access to npc
* requires firmware & hardware support

It's going to be a big change for a SPE app to go from NOSCHED to 
NOSCHED|ISOLATE. Now that we have ISOLATE_EMULATE at the libspe layer, 
there's a much better way to debug/develop isolated apps.

(also, if you're really trying to debug your isolated app by removing 
the SPU_CREATE_ISOLATE flag (but not SPU_CREATE_NOSCHED), wouldn't 
access to a debugger, coredump, and regs be a Good Thing?)

> > However, the main problem is that we'd need to implement the
> > reservation scheme - and that requires time :D
>
> Given unlimited time, I'd rather have an implementation of isolated
> threads without relying on NOSCHED. That would make fewer people
> rely on the odd behaviour of NOSCHED rather than adding more
> complexity to it.

Assisted isolated scheduling gives me nightmares :D

But yes, it'd be a good thing to have one day .. I think. I believe that 
the reservations for NOSCHED would be easier to implement, though.


Jeremy