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 23:03:04
On Sat, Sep 07, 2002 at 02:35:16PM -0700, Jason R Thorpe wrote:
> On Sat, Sep 07, 2002 at 01:50:11PM -0700, Chuck Silvers wrote:
> > ah, ok, this is the bit that was missing. on at least one platform (alpha),
> > circumstances outside the kernel's control require that some of the
> Right, VAX is also like this (PTE array address is in the hardware PCB).
> > however in this context, I don't see why it's a per-LWP.
> > the pmap needs to know which CPUs the pmap has be active on
> > so that it can invalidate TLB entries and such,
> > but why does it need to know which LWP ran on that CPU?
> > does it need to go modify the per-LWP structure again to
> > clear out the copy of the per-pmap data?
> It's "per-LWP" in the sense that LWPs are the scheduling primitive. So,
> when you switch to a new execution context, you're switching to an LWP,
> not to a proc. Basically, the LWP is the data structure that is convenient
> from cpu_switch.
sure, the LWP structure is convenient, and address-space-related info
could be cached in a per-LWP structure, but the address space is
fundamentially not per-LWP, it's per-pmap. the pmap is (part of)
the definition of the address space after all, and pmaps and LWPs
obviously do not map 1-to-1.
> > sorry, I said that badly. the operation I was referring to was the one
> > where you change the address space out from under multiple LWPs.
> > I couldn't tell if there was any other reason for your proposed change
> > because you didn't explain what the problem was. but now you have,
> > and I agree that something does need to be changed.
> > as to what that change should be, wouldn't it be simpler to just
> > change pmap_activate() to take an LWP pointer instead of a proc pointer?
> > when would you ever want to call the two separate interfaces that you
> > propose independently of one another? if they're always used together,
> > it seems simpler to have one interface.
> On the nathanw_sa branch, it does currently take an LWP pointer, rather
> than a proc pointer, since that is the only way you have to get to the
ok, so does that change take care of the immediate problem on the alpha, then?
that change seems totally reasonable to me.
> I'm not saying that anything in the tree right now will tickly this
> condition ... however, the pmap interface in question is used as part
> of a generic vmspace share/unshare facility, and this is a hole in the
> interface spec that can cause grief.
you keep saying that having a single pmap_activate() (even one that takes
an LWP pointer instead of a proc pointer) is a flawed interface, but you
haven't yet explained what it is that you want to do that you can't do
with that interface. if you don't have any immediate need that is
unsatisfied by the existing interface, then why not wait until you have
such a need before changing the interface further? that way, you'll be
sure that the interface change will actually give you what you need.
once you can explain what you want to do, then we can discuss whether
any given interface makes sense.