svn commit: r202889 - head/sys/kern

[Attilio Rao]

2010/1/30 Marius Strobl <marius at alchemy.franken.de>:
> On Sat, Jan 30, 2010 at 04:22:47PM +0100, Attilio Rao wrote:
>> 2010/1/30 Marius Strobl <marius at 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?

I loooked briefly at the protected paths and I guess what you really
want is to use a dedicated global spinlock (because you are going to
access to the pmap of all CPUs, not only the one where you are running
into) which doesn't necessary need to be sched_lock (cpushead is not
sched_lock protected btw). Maybe something more fancy may be done, but
that's simple enough and working.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein