Re: UVM patch for PR port-xen/45975

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

On Mon, Feb 20, 2012 at 10:09:24AM -0800, Chuck Silvers wrote:
> > > > 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.
> > 
> > If the expensive call has to be made before updating the mappings,
> > pmap_update() is not of that much use (or you have to remember operations
> > to be made, and apply them at pmap_update() time, which is not that
> > easy).
> 
> since pmap_kremove() can defer its effects (though I guess it currently 
> doesn't
> for xen, since otherwise your latest patch wouldn't work?  not sure, I haven't
> found the code yet), I would think we would need to call pmap_update() before
> freeing the page in this code.

Right, for x86 (Xen or native)  pmap_kremove writes the PTEs immediatly, but
defer tlb invalidations. In case of Xen, tlb invalidations is done by the
hypervisor if needed when reusing the page as PDP.

> 
> if it's difficult to avoid calling pmap_update() multiple times due to that,
> note that calling pmap_update() extra times doesn't have to cost very much,
> since it can easily return without doing anything if no deferred operations
> are pending.  the x86 pmap_tlb_shootnow() already has a check for this,
> though the x86 pmap_update() could be even cheaper in the case where it
> really has nothing to do.

I'm more concerned for cases where n*pmap_kremove() for one page costs
a lot more than one pmap_kremove() for n pages. There are (non-x86) pmaps
where this is the case, and collecting the data needed in pmap_kremove()
to do it a pmap_update() time isn't cheap either. And if we go
this way, the existing pmap_update() calls are not in the right place to
make sure there's no write mapping behind when a page is freed ...

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