Maxime Villard <max%m00nbsd.net@localhost> writes:
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.
I have previously suggested this - I think the pmaps for native and PV
should diverge. I would also recommend relooking nvmm pmap changes from
this PoV so that the divergence is clear and methodical. If you lead the
excision for nvmm, I will attempt to follow the pattern. This will also
force rethinking the level of abstractions we currently use for PVops.
Unfortunately (for several reasons) I cannot lead this process right now
but again, if you take the initiative, I am happy to review and test
changes.