Re: UVM patch for PR port-xen/45975

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Feb 18, 2012 at 07:49:13PM +0000, Mindaugas Rasiukevicius wrote:
> > [...]
> > 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.

I guess it's the batch'ing of pmap_kremove that's unecessery.
I'm not sure: some pmap_kremove() implementation do what looks like
expensive calls (like PMAP_SYNC_ISTREAM_KERNEL on alpha, pmap_vac_me_harder()
on arm, VAC flushing on m68k/motorola, and so on). Also, some platforms
zero out pte using memset, and it's probably more efficient than zeroing
one at a time

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

So should I move the pmap_update() back ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--