11.1. Computer Organization and Architecture: A Pedagogical Aspect

In this lecture, we continue our discussion with virtual memories. In the last lecture we said that a process generates virtual addresses in order to access memory, a process generates virtual addresses. Therefore, the CPU generates virtual addresses and to get the required data this virtual address must be converted to a physical memory address and from that physical memory address the data must be obtained.

In computer systems, when a program (process) runs, it generates virtual addresses to access data in memory. The CPU produces these virtual addresses, but they need to be translated into physical addresses that correspond to actual locations in RAM. Every time the CPU requests data using a virtual address, this must first be changed into a physical address so the memory controller knows where to find the data.

Think of virtual addresses like addresses in a city where the houses (data) are located. The virtual address is the name of a street, but without knowing the actual coordinates (physical address), you won't be able to reach the house. Just like a postal service needs to convert street names into actual GPS coordinates for delivery, a CPU needs to convert virtual addresses into physical addresses to access data.

This virtual address is divided into two parts: one is the page offset; the other is the virtual page number. The page offset is directly translated and translates translated as it is without any modification for the physical page for the physical page offset. This was because the page size in the virtual memory and the page size for the main memory was same is same.

A virtual address is segmented into two key components: the page offset and the virtual page number. The page offset specifies a specific location within a page, while the virtual page number identifies which page is being accessed. Because virtual and physical memory pages are of the same size, the offset can be reused directly without any changes when calculating the physical address.

Imagine a large library. Each section of the library represents a page, and within each section, there are numerous books. The virtual page number tells you which section to look in, and the page offset tells you exactly which book to pull off the shelf. Since all sections are organized in a uniform way, you don’t need to change how you find the book once you know the section.

The virtual page number is then floated to the page table of the process. So, each process has a page table and this page table is indexed by the virtual page number. In this page table entry if the valid bit is 1, I get the physical page frame number and from this physical page frame number I add the.

Each process maintains a page table, which maps virtual page numbers to physical memory locations. This table includes a 'valid bit', which indicates whether the mapping is correct. If this bit is set to 1, it means the page is present in physical memory, and the corresponding physical page frame number can be retrieved. If the valid bit is 0, it indicates that the page is not in memory and must be loaded from disk.

Think of the page table as a delivery schedule for a catering service. Each order corresponds to a virtual page number, and the valid bit functions as a status indicator. If the status is '1', the food is at the requested address (in memory); if it's '0', the order is still at the restaurant (on disk) and hasn't been delivered yet.

If this bit is off, it means the page is not present in the physical memory. So, if the valid bit is 0 suppose this valid bit is 0, this means that this physical page number that this page table entry contains is invalid. This is not valid if this is 0 and therefore, it means that this page is not there in the physical memory and must be brought from the secondary storage.

A valid bit value of 0 in a page table entry signifies that the corresponding virtual page number does not map to a physical address in memory. Instead, this page is stored in secondary storage (like a hard disk). Consequently, when the CPU tries to access this page, it must stop and initiate a page fault, triggering a process to load the required page from disk into physical memory.

Think of this scenario like trying to find a book in a library that has been checked out. The library's catalog indicates the book's location (but the valid bit shows it's unavailable). So, you have to request the book from a different library (secondary storage) before you can read it.

Therefore, the page table maps each virtual memory page to either a page in main memory or a page on disk. The page table maps each virtual memory page to either a page in main memory or a page on disk. If the valid bit is on, the page table supplies the corresponding physical page frame number.

The purpose of the page table is to manage which virtual pages reside in physical memory and which reside on secondary storage. Therefore, it not only contains mappings to physical addresses but also includes information about where the pages can be found on disk if they are not currently loaded in memory. This mechanism is crucial for an efficient memory management system, allowing dynamic loading and unloading of pages based on the program's needs.

Imagine the page table as a map of a city that tells you which buildings (pages) are currently accessible (in memory) and which are under construction (on disk). If you want to visit a building that's not accessible right now, you can check the map to see where that building is and plan to revisit once it's accessible.

Now, we come to a discussion; we will now do a discussion on the structure of a page table. Page table sizes can be huge; it can be very big. Let us consider a 32 bit computer. So, which has it has a 32 bit logical address space; 32 bit computers its a modern computer.

Page tables can grow significantly large, particularly in systems with 32-bit address spaces. For instance, if a page size is 4 KB, this implies that a total of 1 million entries may be required in a page table. Each entry typically takes 4 bytes, resulting in a 4 MB page table just for one process. This highlights the importance of managing page table sizes efficiently as more processes are initiated, especially in a system with many parallel programs.

Think of a page table as a detailed inventory list for a warehouse. If you stock many items (pages), the inventory list can grow immense very swiftly. Just as a warehouse must manage the space for its inventory efficiently, computer systems must manage the memory required for page tables by optimizing the content and size.

In addition to physical page frame addresses the page table must also contain disk addresses of all virtual memory pages. That is why although logically same we maintain two distinct, two we distinct two data structures; which both are page tables both are indexed by the virtual addresses.

To manage both physical memory and disk storage efficiently, it’s necessary to maintain two distinct page tables: one for physical memory and another for disk addresses. This separation allows the operating system to track which pages are currently held in main memory and which need to be fetched from disk, thereby streamlining memory access and management.

Picture this like a restaurant menu where one side lists what’s available today (physical memory) while the other side shows items that are currently out of stock but can be ordered later (disk storage). This setup allows waitstaff (the OS) to know what's immediately available while also keeping a list of items that can be fetched later.

--