Date: Sat, 30 Jan 2010 17:41:45 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Attilio Rao <attilio@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Rob Farmer <rfarmer@predatorlabs.net>, src-committers@freebsd.org Subject: Re: svn commit: r202889 - head/sys/kern Message-ID: <20100130164145.GB77522@alchemy.franken.de> In-Reply-To: <3bbf2fe11001300722v7dc4e53cvc94cddd60997c79b@mail.gmail.com> References: <201001231554.o0NFsMbx049837@svn.freebsd.org> <b025ceb71001252225r56d4b0c8qe4c6affe338e6f9f@mail.gmail.com> <3bbf2fe11001252310r408a6be4j9bc42618394b3e3d@mail.gmail.com> <20100127215904.GF40779@alchemy.franken.de> <3bbf2fe11001280216p705ed94ev61abc4be654f8cc1@mail.gmail.com> <20100130144036.GA77522@alchemy.franken.de> <3bbf2fe11001300722v7dc4e53cvc94cddd60997c79b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 30, 2010 at 04:22:47PM +0100, Attilio Rao wrote:
> 2010/1/30 Marius Strobl <marius@alchemy.franken.de>:
> >
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100130164145.GB77522>