On Sat, Sep 07, 2002 at 01:50:11PM -0700, Chuck Silvers wrote:

 > ah, ok, this is the bit that was missing.  on at least one platform (alpha),
 > circumstances outside the kernel's control require that some of the

Right, VAX is also like this (PTE array address is in the hardware PCB).

 > however in this context, I don't see why it's a per-LWP.
 > the pmap needs to know which CPUs the pmap has be active on
 > so that it can invalidate TLB entries and such,
 > but why does it need to know which LWP ran on that CPU?
 > does it need to go modify the per-LWP structure again to
 > clear out the copy of the per-pmap data?

It's "per-LWP" in the sense that LWPs are the scheduling primitive.  So,
when you switch to a new execution context, you're switching to an LWP,
not to a proc.  Basically, the LWP is the data structure that is convenient
from cpu_switch.

 > sorry, I said that badly.  the operation I was referring to was the one
 > where you change the address space out from under multiple LWPs.
 > I couldn't tell if there was any other reason for your proposed change
 > because you didn't explain what the problem was.  but now you have,
 > and I agree that something does need to be changed.
 > 
 > as to what that change should be, wouldn't it be simpler to just
 > change pmap_activate() to take an LWP pointer instead of a proc pointer?
 > when would you ever want to call the two separate interfaces that you
 > propose independently of one another?  if they're always used together,
 > it seems simpler to have one interface.

On the nathanw_sa branch, it does currently take an LWP pointer, rather
than a proc pointer, since that is the only way you have to get to the
PCB.

I'm not saying that anything in the tree right now will tickly this
condition ... however, the pmap interface in question is used as part
of a generic vmspace share/unshare facility, and this is a hole in the
interface spec that can cause grief.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>