Date: Fri, 20 May 2011 12:38:41 +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: <20110520103841.GA40497@alchemy.franken.de> In-Reply-To: <20110519195245.GA3039@server.vk2pj.dyndns.org> References: <20110519195245.GA3039@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 20, 2011 at 05:52:45AM +1000, Peter Jeremy wrote:
> [Cc'ing jeff@ as the "owner" of ULE]
>
> I notice sparc64 is now the only architecture that doesn't support
> ULE. According to the sched_ule.c commit log, this is due to lack of
> support for the 3rd argument to cpu_switch(). Followup to r202889,
> committed as r203185 (MFC'd as r203554 and r203573) suggests that
> cpu_switch() has now been fixed. Are there still outstanding issues
> preventing the use of ULE on sparc64 or did removing the #error just
> fall thru the cracks?
>
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. The best thing one can do
there is to call C-wrappers which then call mtx_{,un}lock_spin(),
which isn't very elegant however (I think I've a patch which actually
implements just that though). 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 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).
Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110520103841.GA40497>