SCHED_ULE on sparc64

[Marius Strobl]

On Fri, May 20, 2011 at 10:41:02PM +1000, Peter Jeremy wrote:
> 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).

I don't think these actually acquire a lock, all lock-related I can
identify there are the equivalents of the following:
	atomic_store_rel_ptr(&old->td_lock, mtx);
and:
#if defined(SCHED_ULE) && defined(SMP)
		while (atomic_load_acq_ptr(&new->td_lock) == &blocked_lock)
			cpu_spinwait();
#endif

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

They certainly won't but typically I hit enough problems when trying to
get code developed on x86 or actually written with only x86 in mind to
work on sparc64 that I don't really feel the desire to go out hunting for
generic bugs in that code. In any case my motivation for getting SCHED_ULE
to work on sparc64 suddenly vanished with r171488 for some strange reason.

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

I don't think 16 cores counts as a lot these days :)

Marius