From owner-freebsd-sparc64@FreeBSD.ORG Fri May 20 15:04:44 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18261065673; Fri, 20 May 2011 15:04:44 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9308FC13; Fri, 20 May 2011 15:04:43 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p4KF4dBR041579; Fri, 20 May 2011 17:04:39 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p4KF4dTR041578; Fri, 20 May 2011 17:04:39 +0200 (CEST) (envelope-from marius) Date: Fri, 20 May 2011 17:04:39 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20110520150439.GR92688@alchemy.franken.de> References: <20110519195245.GA3039@server.vk2pj.dyndns.org> <20110520103841.GA40497@alchemy.franken.de> <20110520124102.GA80878@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110520124102.GA80878@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: jeff@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: SCHED_ULE on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 15:04:45 -0000 On Fri, May 20, 2011 at 10:41:02PM +1000, Peter Jeremy wrote: > On 2011-May-20 12:38:41 +0200, Marius Strobl 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