Subject: Re: 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/07/2002 10:55:26
On Sat, Sep 07, 2002 at 10:28:22AM -0700, Chuck Silvers wrote:
> well, really that operation can contain both per-LWP and per-proc
> components. loading a different register set is a per-LWP thing.
> switching address spaces is a per-proc thing. if you switch between
> two LWPs in the same proc, there's no need to switch address spaces
> because you've already got the needed address space.
Right. This is something cpu_switch or the (now machine-dependent)
pmap_activate can know about. I've already done this in the ARM
cpu_switch on the nathanw_sa branch.
> 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).
In your vfork example, right, as it currently stands now, a vfork'd
process will not allocate a new ASN until it execs. The reason is
that the ASN in the pmap it is using is already valid. My patch doesn't
change that, either.
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.
> 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.
-- Jason R. Thorpe <email@example.com>