Re: svs_pmap_sync() svs_pdir_switch() overhead

On Sat, May 23, 2020 at 09:04:26AM +0200, Maxime Villard wrote:
> Le 20/05/2020 ? 11:12, Manuel Bouyer a ?crit?:
> > On Tue, May 19, 2020 at 10:51:52PM +0000, Andrew Doran wrote:
> > > Both of these show up prominently in profiling for me.  This change largely
> > > cures it:
> > > 
> > > 	http://www.netbsd.org/~ad/2020/svs.diff
> > > 
> > > Comments?
> 
> I didn't know kcpuset_isotherset() existed, that is indeed better.
> 
> Not sure the second part is correct though. Suppose:
> 
> cpu0 is executing svs_pdir_switch(), and cpu1 is modifying the PTEs at the
> same time. cpu0 returns to userland before cpu1 finished. [XXX]. cpu1
> finishes, and calls svs_pmap_sync().
> 
> In the [XXX] window, the PTEs could be used by userland. If you copied
> them using memcpy(), some parts of the bytes could contain stale values.

You mean if memcpy() was moving single bytes at a time?  That won't happen,
see:

https://nxr.netbsd.org/xref/src/common/lib/libc/arch/x86_64/string/bcopy.S

Cheers,
Andrew

 
> > I also noticed that the cost is very high on Xen PVH/PVHVM domUs,
> > at last with ~10 year old hardware.
> 
> On old CPUs the cost of the Meltdown mitigation is known to be huge. This
> is because they are slow at flushing+caching TLB entries, and the fact
> that there is no PCID doesn't help either.
> 
> Maxime