Josef “Jeff” Sipek

Putting the V in HVF

After a number of days trying to avoid having to implement the Dynamic Address Translation (DAT) related code, I finally came to the conclusion that I had to…and so I did…in one afternoon. Woohoo! It actually wasn’t all that bad. Sure, it’s not complete, I still need a way to invalidate entries in the TLB, but right now, the only user that exists is the nucleus, so I just set up the address space, load up a pointer to the first level of page tables (called Region-Third-Table), and toggle the right bit in the Process Status Word (PSW). The DAT hardware turns on, and happily starts translating the addresses from virtual to physical.

One thing that struck me as somewhat wasteful was the fact that if I have, say 128MB to set up page tables for (each page being 4kB), I need to set up 32768 page table entries (PTEs)! Sure, if they are physically fragmented, then you have no choice, but if they are in a couple of (if not one) contiguous chunk, then what? You still need 32768 entries. Oh, and have I mentioned that each entry is 8 bytes? That means, that 128MB needs 256kB of PTEs. Now, you can’t just have just PTEs, that would make the translation far too inefficient. You have segment tables (with segment table entries — STEs) which point to sections of the page tables. As it turns out, each STE can point to a section of only 256 PTEs. In other words, the 32768 PTEs will require 128 STEs — at 8 bytes each, that’s just a single page…but…

Now, imagine we have 2 GB to set up page tables for, that’s…
…2147483648 bytes
…524288 pages
…524288 pages table entries
…4194304 bytes of page table entries (= 4 MB)
…2048 segment table entries
…16384 bytes of segment table entries (= 16 KB)
…~4MB overhead for 2GB

Still doesn’t sound that bad…but if the hardware allowed some kind of extent-based PTE, or if for example the STE had a flag that said this is the physical address and the begining of a 1MB chunk of memory (256 * 4kB = 1MB). A whole lot of memory could be saved.

Powered by blahgd