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:

	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.

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>