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

[Michael Ellerman]

On Tue, 2007-07-17 at 01:55 +0200, Arnd Bergmann wrote:
> 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.

It's a little different, but a little the same. My point is from a
user's perspective the scheduling policy shouldn't effect the fact that
I can core dump it etc.

> Also, you can always use regular scheduleable threads during development
> and only switch on the NOSCHED flag for production use.

You could, but IMHO shipping software that you _never tested_ is a bad
idea.

> 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.

That's fine.

> 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.

This is broken. I agree that accessing it with the debugger will screw
with the timing behaviour, there's nothing we can do about that. But if
I want to, I should still be able to debug it. And when I'm finished it
should be rescheduled on the _same spu_.

As far as core dumps go it just makes no sense that NOSCHED contexts
should be discarded, the program is dead anyway.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20070717/0a2997fb/attachment.pgp>