On Jul 20, 2005, at 10:38 AM, David Hopper wrote:

> The issues with Alpha MP are still extant, see port-alpha/25599 for  
> one possible avenue toward stability.  I haven't tried the pmap  
> patches on our own AS1200, mostly because I'm trying to avoid the  
> sickening feeling in my stomach as this production machine locks  
> hard on an MP kernel-- mostly on a Friday night before I leave for  
> vacation.

Hm.  Michael's analysis is spot-on, and Chuq's suggestion is also  
spot-on.

In the pmap_activate() case, it would indeed be safe to avoid  
PMAP_LOCK() for kernel_pmap, since no bits of the kernel_pmap can  
actually change in that path.  However, for pmap_extract(), it is  
not, because it is possible for the kernel to get new PT pages  
(although the kernel's existing PT pages would never change, so it  
may in fact be safe for pmap_extract(), as well, now that I think  
about it -- note that vtophys() does not lock the kernel_pmap even  
though it may do a table-walk).

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).

I don't really like the idea of splsched() during PMAP_LOCK()s.  That  
has the potential to leave interrupts blocked for a long time, which  
no one really wants.

-- thorpej