On Sat, Sep 07, 2002 at 10:55:26AM -0700, Jason R Thorpe wrote:
>  > 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).

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
per-proc (or really, per-pmap) data be replicated in a per-LWP structure.
so in this context, it really is necessary to know not only which
pmap should be active but also which LWP, so that you can copy the
per-pmap data to the right LWP structure.


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

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?


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

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.

-Chuck