SCHED_ULE on sparc64

[Peter Jeremy]

On 2011-May-20 12:38:41 +0200, Marius Strobl <marius at alchemy.franken.de> wrote:
>The main problem with SCHED_ULE on sparc64 is that the MD code
>(ab)uses the global sched_lock of SCHED_4BSD to protect pm_context,
>pm_active and pc_pmap, partially of all CPUs, and SCHED_ULE doesn't
>use/provide such a lock. One could replace the use of sched_lock
>for that with a global MD spin lock but this has the issue that it
>would have to be acquired and released in cpu_switch(), which is next
>to impossible to do properly in assembler.

Definitely messy but MIPS and PPC do it (at least the acquire - I
don't see how the lock is released in either case).

> There might be an alternate approach to
>achieve the required level of protection not involving using a spin
>lock but that needs thorough thinking and testing.

The lack of atomic RMW operations definitely makes sparc messier than
(eg) i386/amd64 here.  It has been a long while since I studied SPARC
assembler in any detail (and that was pre sun4u) so I can't really
help here.

> The bottom line
>is that watching the various mailing lists so far didn't provide the
>necessary motivation to work on that to me though (even today you still
>find reports about performance problems with SCHED_ULE and suggestions
>to use SCHED_4BSD instead, just see 4DD55CE0.50202 at m5p.com as current
>example).

OTOH, not using it won't get the bugs fixed.  My rationale for firing
up the spare V890 at $work was to try and stress some of the big
systems code and SCHED_ULE is supposed to be better at handling lots of
CPUs than SCHED_4BSD.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20110520/38505575/attachment.pgp