It is true that the interfaces in the VM system have changed (and are
therefore FreeBSD specific), but those interfaces are part of the
improvements associated with the VM code. Changing the interfaces
isn't all that difficult, and the hardest part about a port of the
VM code is likely the pmap module changes. One really bad thing
about the original VM code is that the pmap code is called lots
and lots of times. We have mitigated that significantly.
Yes; the pmap code is the major barrier, especially on RISC processors
where the full VM capability is not all in hardware, and requires some
software to go with it. This (and the publically undocumented PPCBug)
are where my PPC code is currently bogged. Without the PPCBug code,
though, I don't have a reliable console, so I've only mentioned this
to you once or twice.
Frankly, it is likely that a VM system that performs as well as
the FreeBSD VM code (and I am not making any relative claims here --
the other *BSDs are making some improvements), is going to require
interface changes relative to the original Lite/2 code.
There are also issues to be considered re: soft updates, if that code
is ever brought in. In a unified VM, soft updates at the FS level
(as in the Ganger/Patt implementation) will degrade to DOW performance
(cv: our other discussion). I'd like to see some incentives for
rethinking the soft updates strategy (it would also avoid the code
duplication necessary in an incremental, per-FS approach).