From owner-svn-src-all@FreeBSD.ORG Sat Jan 30 16:41:47 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81E331065692; Sat, 30 Jan 2010 16:41:47 +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 0A1568FC19; Sat, 30 Jan 2010 16:41:46 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o0UGfjI9000320; Sat, 30 Jan 2010 17:41:45 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o0UGfjMY000319; Sat, 30 Jan 2010 17:41:45 +0100 (CET) (envelope-from marius) Date: Sat, 30 Jan 2010 17:41:45 +0100 From: Marius Strobl To: Attilio Rao Message-ID: <20100130164145.GB77522@alchemy.franken.de> References: <201001231554.o0NFsMbx049837@svn.freebsd.org> <3bbf2fe11001252310r408a6be4j9bc42618394b3e3d@mail.gmail.com> <20100127215904.GF40779@alchemy.franken.de> <3bbf2fe11001280216p705ed94ev61abc4be654f8cc1@mail.gmail.com> <20100130144036.GA77522@alchemy.franken.de> <3bbf2fe11001300722v7dc4e53cvc94cddd60997c79b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe11001300722v7dc4e53cvc94cddd60997c79b@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Rob Farmer , src-committers@freebsd.org Subject: Re: svn commit: r202889 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 16:41:47 -0000 On Sat, Jan 30, 2010 at 04:22:47PM +0100, Attilio Rao wrote: > 2010/1/30 Marius Strobl : > > > > I think the idea behind using sched_lock in the sparc64 code is > > to piggyback on it for protecting the pmap and take advantage of > > the fact that it's held across cpu_switch() anyway. If that's > > correct it should be possible to replace it with a separate > > spinlock dedicated to protecting the pmap or given that due to > > the macro madness involved in mtx_{,un}lock_spin() it's hard to > > properly call these from asm by calling spinlock_{enter,exit}() > > directly. > > Even if that is the case there is no reason to not call > thread_lock()/thread_unlock() (which will acquire the correct > sched_lock or do the handover in the sched_4bsd in the right way) and > keep an unified spinlock in order to keep cpu_switch() simple and > still offering pmap protection over context switches. > It's not clear to me what threads to use in order to get this to work the right way, for pmap_release() I'd use curthread and for pmap_activate() I'd just pass td on to thread_{,un}lock()? Whould the general approach of using thread_{,un}lock() for pmap protection also do the right thing in case of ULE? Marius