re: CVS commit: src/sys/arch/sparc/sparc

[matthew green <mrg%eterna.com.au@localhost>]

moved to port-sparc, from source-changes-d:

> > > Module Name:      src
> > > Committed By:     chs
> > > Date:             Sun Nov  4 00:32:47 UTC 2012
> > > 
> > > Modified Files:
> > >   src/sys/arch/sparc/sparc: locore.s pmap.c
> > > 
> > > Log Message:
> > > in cpu_switchto(), remove the MP-unsafe code to mark a pmap active on a 
> > > CPU,
> > > pmap_activate() already does this.  add MP locking to pmap_activate()
> > > and pmap_deactivate().  move flushing of user windows and virtual caches
> > > from pamp_activate() to pmap_deactivate().
> > 
> > 
> > hmm.  this makes pmap_deactivate() do things in UP that weren't being
> > done before at all.  switching to/from kernel/lwp for the same lwp will
> > now be flushing the ctx every time.  that seems suboptimal?
> 
> do you just mean that I should have left the #ifdef MULTIPROCESSOR
> around the sp_tlb_flush()?  or something more than that?

i'm not sure exactly.  i had a quick look at editing it back again
but i didn't like the result.  i'm imaging a system that only flushes
the previous context in pmap_activate() if it was not the same.  ie,
pmap_deactivate() shouldn't always flush.  i don't think this should
be MULTIPROCESSOR-related either.

> > we should really update PMAP_LOCK() to not be kernel lock.
> 
> agreed.
> 
> beyond that, there's still plenty of room for improvement on most platforms.
> I think the best example in our tree at this point is the x86 scheme
> of deferring the MMU-switch work to points where we're actually about to
> reference user mappings, eg. returning to user mode, copyin/copyout, etc.

many pmaps can have simpler locking now, since the rmind-uvmplock
branch was merged.  i have a started reducing the use of
sparc64/pmap.c:pmap_lock though there is plenty more to go.

thanks.


.mrg.