On Mon, Sep 02, 2002 at 02:34:39PM -0700, Jason R Thorpe wrote:
> On Fri, Aug 30, 2002 at 12:34:54AM -0700, Chuck Silvers wrote:
> 
>  > > (FWIW, I'm planning on changing the pmap_activate() semantics to
>  > > address a problem on the nathanw_sa branch).
>  > 
>  > ok, but is that related to this?  what sort of change would you propose?
> 
> It's not really related to this, but it overlaps in a way.
> 
> The problem is that, as it stands, pmap_activate() has "fuzzy" semantics:
> 
> 	1. Sometimes, it's used to activate the address space for a process
> 	   that is being switched to.  Many platforms use this to make sure
> 	   the PT base is set in the PCB, or something like that (or allocate
> 	   an ASN, or mark the pmap active on CPU #n for MP TLB shootdown,
> 	   etc.).  In these cases, it is usually (always?) called when the
> 	   target proc != curproc.
> 
> 	2. Sometimes it's called to say that the currently running process
> 	   has a new virtual address space (e.g. uvmspace_share/unshare).
> 
> This has problems in the LWP/SA universe.  In that world, operation (1) is
> really per-LWP, and operation (2) is really per-proc.  A little more detail:

how is operation 1 per-LWP?  the address space is the same for each LWP
in a process, so wouldn't they use the same ASN, etc?
if the PCB is going to be per-LWP, shouldn't there be a corresponding
structure that is per-proc, and wouldn't any address space information
be in that structure instead of in the PCB?

(though I'd think that the per-LWP structure would be an LCB,
leaving "PCB" per-process.  it does stand for "process control block"
after all.)


> 	1. In the LWP/SA universe, this operation remains largely unchanged.
> 
> 	2. In the LWP/SA universe, this operation needs to traverse the list
> 	   if LWPs, and update their PCBs, etc.  This might involve sending
> 	   IPIs to other CPUs, if LWPs for the current process are active on
> 	   other CPUs.

when would a process get a new address space while it has multiple LWPs?
the address space changing out from under an LWP would cause a lot of problems,
I'd think.  could you give an example of how this would work?

-Chuck


> What I'd like to do is split the two operations into two different calls:
> 
> 	pmap_activate(struct proc *p) -- this will be essentially the same
> 	operation as it is now, except for the "and reload PT base register
> 	if curproc" part will go away.  I.e. it will simply make a proc's
> 	pmap (or an LWP's proc's pmap) ready to be used by the current
> 	processor.
> 
> 	pmap_newvmspace(struct proc *p, struct pmap *newpmap) -- this will
> 	be used to switch a process from one VM space to another.  It also
> 	occurs to me that this could be used for your exec optimization
> 	(where you currently pmap_activate(&proc0), instead you would
> 	so pmap_newvmspace(p, pmap_kernel())).
> 
>  > well, I could just go ahead and fix all the pmap_activate() implementations
>  > so that wouldn't need to be conditionalized.  I don't think either of us
>  > is going to go and implement pmap_predestroy() or pmap_remove_all()
>  > for all pmaps anytime soon, so that would need to be conditionalized
>  > either way.  I don't see not much difference on that front.
> 
> Actually, I *would* like to make the above change relatively soon, as it
> will make it possible to undo some hacks on the nathanw_sa branch, which
> will mean we can concentrate on other stuff there and hopefully merge it
> a little sooner :-)
> 
> -- 
>         -- Jason R. Thorpe <thorpej@wasabisystems.com>