On Thu, Aug 29, 2002 at 12:41:28AM -0700, Jason R Thorpe wrote:
> On Thu, Aug 29, 2002 at 12:10:35AM -0700, Chuck Silvers wrote:
> 
>  > > Why not just make a pmap_remove_all() to just nuke all user mappings from
>  > > a pmap, and allow it to use the shortcut?  Then exec/exit can use it before
>  > > they do the normal remove steps, so that all the pmap_remove() steps done
>  > > during the uvm_unmap's will be noops?
>  > 
>  > you could do this with the pmap_predestroy() interface as I described it.
>  > in pmap_predestroy(), remove all the mappings and mark the pmap as empty.
>  > in pmap_remove(), just return immediately if the pmap is marked empty.
>  > so this is an implementation issue, not an interface issue.
> 
> Sure, but I just don't like the idea of a pmap_predestroy() which might
> or might not do something clever ... 

what's wrong with interfaces where the caller doesn't know the underlying
implementation?  that's kind of the point of having a well-defined interface.
:-)


> and it's not like you're really destroying anything ...
> use pmap_remove_all() in the exec path, too, rather
> than the separate pmap_activate() hack?

well, this started off from the exit path, where you really are
destroying the pmap.  I changed the exec path too once when I realized
that it would help there as well.


> (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?


> Seems like the one interface can trivially do both, and the new interface
> can be naively implemented internally in terms of pmap_remove() in order
> to avoid having to conditionalize all this stuff...

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.

-Chuck