13.2.2.1. Context Switch with Page Tables in Hardware

Now, when the page table is in hardware I have to reload all the registers in page table during a context switch because that is part of the saved state. If the page table is in memory it is sufficient to load the page table base register corresponding to this process. Because the page table is in memory; I only need where in memory the page table starts.

When the page table is stored directly in hardware, each time a context switch occurs (when the CPU switches from one process to another), all necessary registers—including the entire page table—must be reloaded. This is because the state of the process, which includes the page table's information, is considered as part of its 'saved state'. On the other hand, if the page table is stored in memory, only the base register pointing to the start of that page table in memory needs to be reloaded during a context switch. This distinction highlights the efficiency of using memory for page tables, especially when dealing with larger or more complex processes.

Think of a library (representing memory) versus a collection of books in your own room (representing hardware). If you keep all your books in your room, every time you want to read a different book (switch processes), you have to take out every single one and put it back depending on what you want. But if you keep a few in your room and the rest in the library, you only need to remember where the library is and what section your book is in, making it faster to switch between reads.

An example of such hardware implemented page tables is the DEC PDP 11 architecture. The DEC PDP 11 architecture is a 16 bit small computer. So, it has 16 bit logical address space with 8 KB page size.

The DEC PDP-11 is a historical example of a computer architecture that used hardware page tables. It operates on a 16-bit logical address space and supports a page size of 8 KB. This implies that in a 16-bit address scheme, the offsets and page numbers can be calculated based on the page size. In this case, a total of 8 pages fit in the addressable space, making it manageable for hardware implementation but impractical for larger systems, demonstrating the limitations of hardware page tables in more extensive applications.

Imagine a small storage room (the PDP-11's hardware page table) containing a limited number of boxes (pages) where you can only store a certain number of items. If you need to store more than those boxes allow, such as a bulk order of supplies, you would need to switch to a much larger warehouse (software-based paging), which can accommodate many more items and is more flexible.

However, obviously, such hardware implementation of page tables are impractical for computers with very large address spaces.

While hardware page tables work efficiently for smaller systems like the DEC PDP-11, they become impractical for modern computers with large address spaces. For instance, in a 32-bit computer with 4 KB pages, the amount of page table entries required can total into the millions. Storing such vast amounts of data in hardware is unrealistic because of register limitations, leading to inefficiencies in processing and context switching.

Imagine trying to store thousands of files in a tiny drawer (the hardware page table). As your collection grows, you quickly run out of space. In a more practical solution, you would move your documents to a filing cabinet (memory), which has the capacity for extensive organization without cramped spaces, allowing for efficient retrieval when needed.

So, therefore, to copy one word from memory it takes 100 nanoseconds. If each process runs for 100 milliseconds and this includes the time to load the page table what fraction of the CPU time is devoted to loading the page tables.

When we assess the impact of context switches on CPU time, we can calculate how long it takes to load the page table entries from memory. If each word (or entry) takes 100 nanoseconds to load and a process runs for 100 milliseconds, we can determine the percentage of CPU time that is simply spent loading page tables. This calculation reveals a significant overhead if page tables are large, making context switching even slower and highlighting the necessity for efficient page management strategies.

Consider a restaurant kitchen where a chef is responsible for preparing meals (the CPU tasks). If every meal requires the chef to fetch ingredients from a storage room (memory), the time spent just retrieving those ingredients (loading page tables) massively cuts into the time they can actually cook. If the kitchen handling inefficiently limits the ability to prepare dishes, it leads to long wait times for customers (processing delays).

--