Subject: Split pmap_activate() into pmap_activate() and pmap_newvmspace().
To: Chuck Silvers <email@example.com>
From: Jason R Thorpe <firstname.lastname@example.org>
Date: 09/02/2002 14:34:39
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
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
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 <email@example.com>