Care and Maintenance of the TLB
The MIPS TLB is "just" a collection of translation entries. Entries get into it purely by the refill handler's action. Most entries get overwritten in the same way, of course. But sometimes the kernel needs to change a page table entry, and then it's important to invalidate any copy in the TLB.

For a single entry, we can look up the TLB entry using the virtual address + ASID of the original entry, doing a tlbp: If the matching entry is there, we can overwrite that page's entry with an invalid one.

Sometimes, though, you need to do surgery on a larger scale. The ASID mechanism allows the TLB to hold entries for 256 different memory maps, but a Linux system will commonly run more than 256 processes between start-up and shutdown.

So there are times when a whole batch of translations must be rescinded, because the ASID is going to be recycled for a new process and the old entries would be damagingly wrong.

There's no elegant way of doing that. You just have to iterate through all the TLB entries (index values go in the Index register), read each entry out into the usual registers, check the ASID value retrieved into EntryHi(ASID), and invalidate any that match the victim ASID value.

Memory Translation and 64-Bit Pointers
When the MIPS architecture was invented, 32-bit CPUs had been around for a while, and the largest programs' data sets were already moving up toward 100 MB - the address space had only 6 bits or so to spare. (Historically, application program demand for memory space seems to have grown at about three-quarters of a bit per year.)

There was therefore every reason to be reasonably careful with the 32-bit space and not to reduce it by profligate fragmentation; this is why application programs (running with user privilege) keep 31 bits' worth of addressing for themselves.

When the MIPS III instruction set introduced 64-bit registers in 1991, it was leading the industry and, as we discussed in section 2.7, MIPS was probably four to six years ahead of real pressure on a 32-bit address boundary.

The doubling of register size only had to yield a few bits of extra address space to be remarkably future-proof; it's been more important to be cautious about the potentially exploding size of OS data structures than to make efficient use of all address space.

The limitations to the practical address space resulting from the basic 64-bit memory map are not going to be reached for a while; they theoretically permit the mapped user and other spaces to growto 61 bits without any reorganization. But so far, a 40-bit user virtual space has been ample.

Most other 64-bit Linux systems have 8-Kbyte pages, but that would be annoying for MIPS. The MIPS TLB can map either 4 Kbyte or 16 Kbyte in a single entry, but not 8 Kbyte, so 64-bit MIPS kernels use 4-Kbyte pages, with 16-Kbyte pages a desirable option in some brave future.

If you take a look back at Figure 14.4 and imagine a set of intermediate (PMD) tables between the PGD and PTEs, you can comfortably resolve a 40-bit virtual address in a three-level table. We'll leave details to those enthusiastic enough to read the source code.

This series of articles is based on material from "See MIPS Run Linux," by Dominic Sweetman, used with the permission of the publisher, Morgan Kaufmann/Elsevier, which retains full copyrights. It can be purchased on line.