From Newsgroup: comp.arch

On 2/9/26 12:36 AM, Robert Finch wrote:

There used to be separate two bits in my MMU project PTE to
encode the type and a shortcut page indicator. They were
combined into a single two-bit field, 0=PTE,1=PTP, and
2=shortcut. That leaves an extra unused code. I am wondering
what to use the code for. The only thing I can think of ATM is a
meta-data record indicator.

By "meta-data record indicator" do you mean 'invalid' (i.e.,
whatever information is in the other bits is managed by the OS)?

I have also been considering PTEs that are not a power-of-two in
size. For instance, 48-bits or possibly 56 bits. The PTEs would
be stored in the last part of a page with a page header and
other information at the beginning of the page. For an 8kB page
the last (or middle) 6kB would be PTEs. IDK what the header
would be used for, other than perhaps some sort of error
management. That is, if the first part or the last part of the
page was overwritten, it could generate an error. Same as a
header on a block of memory.

I think one might want blocks of PTEs to be within a minimum
memory access chunk (cache block or smaller). This avoids having
to fetch two cache blocks for a PTE (if the memory system is
limited to aligned fetches) and allows the extra bits in the
cache block to be applied to the PTEs in that chunk (without
having to fetch separately from the top of the table).

With 32-byte chunks and 48-bit PTEs, one would have 16 bits of
chunk-local metadata in most chunks. (Special casing one chunk
feels extra funky somehow.) 16 bits does not seem like much.
Giving all the bits saved from a smaller PTE to provide chunk-
local information — with a power-of-two PTEs per chunk — might
be interesting. It is not clear if it would be useful to have
policies applied to 4- or 8-page chunks.

When a chunk could be coalesced into a single page in terms of
translation, the address portions of all but one PTE could be
repurposed (in theory). I do not know what information one would
want to pack into such space. One interesting possibility would
be to increase the physical address space, though that does not
seem that useful (because of the awkwardness of applying only to
"large" pages) and would not use that many bits.

Having some information be common to a group of pages could save
a few bits, but managing the extra complexity is probably
something OS developers would avoid. E.g., if a group of pages
shared the most significant N bits of translation — sort of inverted-from-usual page coloring — most OSes would just have
the allowed physical address space be N bits smaller.
--- Synchronet 3.21b-Linux NewsLink 1.2