14.2.2. Cache Access and Structure

During a page fault when I do not have the required data in memory, I incur a page fault. [...] I have a page fault, then I serve the page fault, then I will restart the memory and then in the subsequent memory reference I will get the data that I sought for in the physical memory.

A page fault occurs when a program attempts to access data that is not currently in physical memory. The system checks the page table and finds that the corresponding page is marked as invalid (the valid bit is 0). In this case, the operating system needs to handle this page fault. It first determines if the access was to an invalid memory reference or if the page is simply not in memory. If the address is valid but not currently in memory, it will locate a physical page frame to load the required page from the disk into memory. Once the page is loaded, the system updates the page table until finally, the program can access the needed data.

Think of a library where a patron (the program) requests a book (data). If the book isn’t available on the shelf (memory), the librarian (operating system) checks if the book exists in the library’s catalog (page table). If it does, but it’s currently checked out (not in memory), the librarian brings the book from a storage area (disk) before presenting it to the patron.

I need to find a physical page frame. [...] and then it will swap page into this frame via scheduled disk operation.

When a page fault occurs, and the OS determines that a page is not in memory, it needs to find a free physical page frame in which to load the required page. If free frames are limited, the OS may need to replace an existing page which involves swapping. It sends the request to the disk to retrieve the data, and this can be a slow process due to seek time—waiting for the disk to find the correct data. Once obtained, the page is swapped in, allowing subsequent accesses to be faster since the data is now in memory.

Imagine a busy restaurant where chefs (OS) keep running low on counter space (physical memory). When a new dish (data) needs to be prepared but space isn’t available, they might have to temporarily remove an existing dish that’s been finished (swap existing page) to make room for the new one.

After I have brought in this page I know the page number. [...] then I will restart the instruction that caused the page fault.

Once the required page is loaded into memory after a page fault, the operating system updates the page table. This includes marking the page as valid and recording its physical page number. Following this, the instruction that triggered the page fault is restarted. This means that the program can now proceed as if the page fault had not occurred, since the required data is now available in memory.

Returning to the library scenario, once the librarian retrieves the requested book and places it on the table, the patron can now read from it, and they pick up where they left off without any disruptions.

Now, we will take an example of a practical architecture which the TLB of a practical architecture...The TLB [...] and a cache hit.

The Intrinsity FastMATH architecture employs a Translation Lookaside Buffer (TLB) to accelerate virtual to physical address translations while handling both instructions and data. This architecture operates with a physical address that is divided into tag, index, and offset parts to efficiently manage cache access. If a request is met with a TLB hit, the cache can be accessed faster without having to hit the page table again, increasing efficiency overall.

Imagine you have a high-tech filing cabinet (TLB), which provides quick access to frequently used documents (data). When you look for a document (address) and find it in the filing cabinet, you don’t need to check the main storage room (page table) every time. It's much quicker to locate it directly in the cabinet.

When there is a TLB hit, when there is a TLB hit I get the corresponding let us say the TLB [...] using the block offset as the select line.

In the event of caching, if the TLB successfully finds the address mapping, the system can directly access data in the cache. The address is split into parts, enabling a faster lookup in the cache. If the required data isn't found in the cache (a cache miss), the system then has to access physical memory, which is a slower process. Understanding how the cache and TLB work together is essential for optimizing access speed and resource usage.

Consider a fast-food restaurant. The drive-thru (TLB) lets customers place orders quickly by having their most common selections pre-prepared. If an order falls outside those options (cache miss), an employee must manually check the full menu (physical memory/restaurant kitchen) to fulfill the order, which takes more time.

--