On Sat, Sep 07, 2002 at 10:28:22AM -0700, Chuck Silvers wrote:

 > well, really that operation can contain both per-LWP and per-proc
 > components.  loading a different register set is a per-LWP thing.
 > switching address spaces is a per-proc thing.  if you switch between
 > two LWPs in the same proc, there's no need to switch address spaces
 > because you've already got the needed address space.

Right.  This is something cpu_switch or the (now machine-dependent)
pmap_activate can know about.  I've already done this in the ARM
cpu_switch on the nathanw_sa branch.

 > except that the address space is per-proc instead of per-LWP.
 > now that I think about it, any per-proc stuff related to the address space
 > probably just belongs in the pmap structure, so that procs sharing the pmap
 > can share it.  eg. there's no need for a vfork'd process to allocate a new
 > ASN until it execs, that kind of thing.  if the vfork'd process exits
 > before execing, allocating an ASN for it would be a waste.

Sure, and the address space is described by a per-process data structure.
However, on many platforms, it is a per-execution-context (thread) data
structure that contains address space information (this is true on e.g.
Alpha -- the PTBR is in the PALcode PCB).  On e.g. i386, the pagedir PA
is merely cached in the PCB for convenience (because the PCB is readily
available in cpu_switch, whereas the pmap structure is not).

In your vfork example, right, as it currently stands now, a vfork'd
process will not allocate a new ASN until it execs.  The reason is
that the ASN in the pmap it is using is already valid.  My patch doesn't
change that, either.

There is another per-LWP operation on the address space... which processor(s)
is a pmap in use on?  Since LWPs run on processors, not procs, marking the
pmap as active is a per-LWP operation.

 > ok, let's wait until there's a practical use for such an operation
 > before we consider changing the pmap API for it.  :-)

The practical application is "clean up some nasty ambiguities as to
what pmap_activate does".  Right now, pmap_activate is used in different
ways by every platform, and there are subtle semantic differences that
are downright confusing.

Also, I already said, this will help clean up some REAL PROBLEMS in the
nathanw_sa branch (right now, pmap_activate() on alpha is somewhat broken
there -- because of the curproc/curlwp confusion, and there's no sane way
to clean it up without clearly separating the per-proc and per-lwp operations).
I could certainly just commit this patch there and we'll simply pull it in
when nathanw_sa gets merged back, but I'd prefer to do it on the trunk first.

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