Re: Utility of PV on non-obsolete hardware

[Cherry G. Mathew <cherry%zyx.in@localhost>]

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. 

-- 
~cherry