On Jul 20, 2005, at 7:21 PM, Jason Thorpe wrote:

> Ok, so maybe a nice *optimization* would be to skip the PMAP_LOCK()  
> for kernel_pmap (indeed, make pmap_activate() a near-no-op) in  
> pmap_activate(), and just defer to vtophys() in the pmap_extract()  
> case.
>
> That said, releasing the sched_lock before calling pmap_activate()  
> would be the right way to solve this problem.  Unfortunately, that  
> would mean having to do a few things twice:
>
> - swpctx to switch to the new LWP's kernel stack (but stay on the  
> kernel's pmap!)
> - set up the new curlwp, etc.
> - pmap_activate()
> - swpctx again to potentially load the new PTBR and ASN
>
> It would just be nice to avoid calling swpctx twice, because swpctx  
> is not exactly cheap (and it's especially expensive on processors  
> that don't have ASNs).

Actually, I thought about this some more.  It would be possible to  
avoid locking in pmap_activate() for *all* pmaps, if a new lev1map  
were allocated with each pmap.  We currently allocate a lev1map when  
the first mapping is entered into the pmap (and free it when the last  
mapping is removed; this is meant to help free pages back to the VM  
system when under memory pressure).  If pm_lev1map never changed,  
then pmap_asn_alloc() would not require the pmap to be locked in  
order to do its work, because pm_lev1map is the only global field in  
the pmap that must be accessed serially; all of the other fields are  
per-CPU.  And you can guarantee that the pmap is not going to be  
recycled when this happens, because by definition an LWP that uses  
the pmap is about to run.

So, that would neatly avoid the entire situation.  If I cook up a  
patch, would someone be willing to test it?  (I don't have an MP  
Alpha system that is in a runnable state, at the moment.)

-- thorpej