Re: svs_pmap_sync() svs_pdir_switch() overhead

[Maxime Villard <max%m00nbsd.net@localhost>]

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.

> 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