Re: Tonight's tradeoff

EricP wrote:

MitchAlsup1 wrote:

Stephen Fuld wrote:
 

So the optimum is, at least to some degree, usage dependent. Of course, this is all an argument for multiple page sizes.

 Which My 66000 provides, but it also provides big pages that can have an
extent [0..extent-1] so you can use a 8GB page to map anything from 8KB
through 8GB in a single PTE. The extent-bits are exactly the bits not
being used as PA-bits.

By the way, I borrowed your extent idea (thank you :-) ) as when combined
with skipping from the root pointer to a lower level, it can be used to
map the whole OS code and data with just a couple of PTE's.
This eliminates table walks for most OS virtual addresses and
could allow a few 'pinned' TLB entries to map the whole OS.

This achieves a similar result to my Block Address Translate (BAT)
approach but without requiring a whole separate MMU mechanism.

The idea is for the OS to be separated into static and dynamic sets
of code and RW data. The static parts are always resident in the OS
plus any mandatory drivers. The linker packages all the static code
and data together into two huge RE and RW memory sections at specific
high end virtual addresses, aligned to a huge page boundary.

The extent feature allows the OS static code and data to be loaded
into just the portion of a huge page that each needs, with any unused
remainder in the huge pages being returned to the general pool as
smaller pages (so no wasted space in the 1GB or 8GB pages).

Those Huge page boundaries can be achieved at nominal page boundaries
with a bit of paravirtualization help by HyperVisor simply because they
are in GuestOS PaS = HV VaS.

And voila - two PTE's map the whole static OS code and data
which can be permanently held in two MMU mapping registers.

And can be as big or small as GuestOS desires.

With one more for the graphics memory and the bulk of
table walks for system space can be eliminated.

And so much for Kernel excursions wiping out the TLB.