13.2.4.1. TLB Hit and Miss Handling

When we get a TLB hit, we obtain the physical page number and can then access the data from physical memory directly. If we're writing to this memory, we set the dirty bit to indicate a modification.

A TLB (Translation Lookaside Buffer) hit occurs when the virtual page number we are searching for is found in the TLB. This means we have a direct mapping from this virtual page number to a physical page number. Once we retrieve the physical page number, we can easily access the data in physical memory by adding the page offset (which comes from the original virtual address) to this physical page number. Additionally, if we modify any data during this process, we must set a 'dirty bit' for that page to indicate that it has been changed and needs to be written back to disk later.

Imagine trying to find a book in a library. A TLB hit is like having a library catalog (the TLB) that tells you exactly which shelf the book (data) is on. If the book is on the shelf, you go directly to get it without searching every book. If you take notes (modify data) in the book, you make a note (set the dirty bit) that the book is now updated and needs to be returned to its original state later.

In the event of a TLB miss, we need to check if the data is present in memory. If the physical page number is in the page table, we retrieve it and bring it back into the TLB. However, if it's not, we incur a page fault and must find a free page to load the data from disk.

A TLB miss happens when the virtual page number is not present in the TLB, indicating that we need to consult the page table stored in memory. There are two scenarios here: 1) If the corresponding physical page number exists in the page table, we can retrieve it, store it in the TLB for faster access in the future, and then use it to access the required data in physical memory. 2) If the mapping from the virtual page number to the physical page number is missing in the page table, it means we have a page fault. This requires us to find a free page frame in memory, load the required data from disk into that frame, update the page table accordingly, and finally load the entry into the TLB.

Think of a TLB miss like going to a library and realizing the book's location isn't in your catalog. First, you check the library's larger storage database (the page table). If the book is found in storage, you take it, put it in your catalog for future reference, and access it. If the book isn’t found at all, it’s like needing to bring it in from an off-site storage unit (disk), which takes more time and may involve other steps (like clearing out space for the new book).

When a page fault occurs, the CPU raises an exception, trapping the operating system to manage the fault. The OS must find a free page frame for the requested page and update the page table accordingly.

A page fault is a specific case when the data needed cannot be retrieved because the corresponding page is not in memory. When this occurs, the CPU interrupts its current tasks and notifies the operating system (OS) to handle the error. The OS then has to determine if there's any free page frame available to store the required data temporarily. If it finds a free page, it retrieves the necessary data from disk and updates the page table to reflect this new mapping. Afterward, it may also need to update the TLB with this information for quicker access in the future.

Imagine you’re in a library, and the book you want is checked out to someone else (page fault). You have to ask the librarian (operating system) about it. The librarian checks if they can reserve a free study room for you to read the book when it comes back or if they can get a copy from a different library (disk). Once the book is returned and you get your reserved study room, the librarian updates the records to show the book is available now.

The TLB typically contains a small number of entries (16 to 512) with high hit rates (99.9%). The associativity allows any entry to be replaced, which can influence the cost and efficiency of access.

TLBs are designed to be small but highly effective caches that store recently used translations from virtual to physical addresses. They usually have a limited number of entries—which can range from 16 to 512—which balances speed and memory usage. This structure allows for very high hit rates, as TLBs capitalize on the temporal and spatial locality of memory accesses—the more you use certain pages, the more likely they are to be present in the TLB. The flexibility in replacing any entry helps reduce delays in accessing data, though it can incur additional costs in searching for replacements when a miss occurs.

Think of the TLB like a small but efficient pantry in your kitchen. It only holds a handful of your most-used ingredients so you can quickly grab them without searching through your large grocery store. Most of the time, you can find what you want right in the pantry (hit), but occasionally, you can't find something, and you need to go to the store (TLB miss). The more often you use certain spices, the more likely they will stay stocked in the pantry long-term (high hit rate).

--