Re: UVM patch for PR port-xen/45975

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> On Sat, Feb 18, 2012 at 10:12:36AM -0800, Chuck Silvers wrote:
> > On Sat, Feb 18, 2012 at 07:01:24PM +0100, Manuel Bouyer wrote:
> > > >  - the calls to pmap_update() should be moved along with the calls
> > > > to pmap_kremove().
> > > 
> > > But not all pmap_kremove() are followed by a pmap_update() in the
> > > initial code. Is it a bug ?
> > 
> > yes.  we don't currently defer TLB invalidations from pmap_kremove() on
> > x86 (or probably any platform), but if we start doing that then the
> > pmap_update()s are needed.
> 
> Note that some places are doing the pmap_update(), but not immediatly
> after uvm_km_pgremove_intrsafe(). By adding a pmap_update() in
> uvm_km_pgremove_intrsafe() we may be doing it twice.
> 
> I've added pmap_update() to uvm_km_pgremove_intrsafe() and removed
> pmap_update() calls that were immedialy following a
> uvm_km_pgremove_intrsafe.
> 
> I also implemented the idea of removing the mappings and freeing page
> in batch of 16 entries. Updated patch attached, I'm re-running the
> build.sh -jx release tests. This should also fix the problem in the native
> case as there's no #ifdef any more :)

This is unnecessary (due to deferred invalidations), please keep it simple.
Note that the expensive TLB flushes is the reason why optimisations like
here exist:

http://nxr.netbsd.org/xref/src/sys/uvm/uvm_map.c#2310

P.S. During rmind-uvmplock branch work, I checked all pmap_[k]remove()
cases, that they have pmap_update() and there are no race conditions,
so we should be fine.

-- 
Mindaugas