Date: Fri, 20 May 2011 17:04:39 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Peter Jeremy <peterjeremy@acm.org> Cc: jeff@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: SCHED_ULE on sparc64 Message-ID: <20110520150439.GR92688@alchemy.franken.de> In-Reply-To: <20110520124102.GA80878@server.vk2pj.dyndns.org> References: <20110519195245.GA3039@server.vk2pj.dyndns.org> <20110520103841.GA40497@alchemy.franken.de> <20110520124102.GA80878@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 20, 2011 at 10:41:02PM +1000, Peter Jeremy wrote: > On 2011-May-20 12:38:41 +0200, Marius Strobl <marius@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110520150439.GR92688>