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

Yes.  Such architectures are free to follow performance improvements made
on x86 and MIPS.  It is the reason why we have pmap_update() in pmap(9) API.
Also, for many architectures and older CPUs TLB flushes are not that
expensive as in e.g. modern x86.

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

Yes, please.

Thanks!

-- 
Mindaugas