On Wed, Aug 28, 2002 at 10:50:51AM -0700, Jason R Thorpe wrote:
> On Wed, Aug 28, 2002 at 07:41:29PM +0200, Jaromir Dolecek wrote:
> 
>  > I wonder if there is need for this. Perhaps this could be made
>  > more universal, and pmap internal structures synced on pmap_update()? 
>  > This might even some other operations using many pmap_remove()s faster.

hmm... yea, that would work.  having a separate interface to tell
the pmap code that the pmap is going away is a bit better though,
since with the extra hint, the pmap can avoid doing any cache or
TLB flushes at all, whereas your way it would still need to do a
round of flushing per exit.  well, I suppose we could arrange for
pmap_destroy() to be called after all the pmap_remove()s but before
pmap_update() in the exit path.

I think I still like the separate interface better, it seems less contorted.

it would be entirely possible to do the non-destroy multi-remove optimization
you describe anyway, though I think the number of applications for which
it would make any difference is vanishingly small.


> 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.

-Chuck