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