Re: Utility of PV on non-obsolete hardware

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

I hope we will be able to retire XenPV sooner than later. We have too many
shades of x86 (between native-32, native-32-pae, native-64, XenPV-32-pae,
XenPV-64, XenPVHVM*), and it is becoming impossible to understand what the
code really does. Meanwhile, the x86 architecture is also getting increasingly
complex, and there are planned future changes that will modify the paging
logic. If we ever want to support any of that, we will either have to retire
certain configurations, or split the code and give a separate pmap (among
other things) to the different configurations.

This would ease maintenance, which would ease support for future features
and also the already existing ones.

For example the other day I was playing with tprof, and noticed that about 10%
of the TLB misses we get during a build.sh are caused by the recursive PTE
slot. If we were using the direct map, almost all of these misses would vanish.
Should I add another ton of #ifdefs in all directions just to get native-64 to
use the direct map in order to reduce TLB misses?

In having so many configurations that share the same code, we just end up
using the least performant options to accommodate everyone. This is not really
smart, it's even completely dumb.