[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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,
> > 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.
Main Index |
Thread Index |