Memory Management: Paging, Virtual Memory, Page Replacement, Segmentation, and Thrashing

13.1 Paging Review: Pages, Frames, and the Page Table

13.1.1 Pages, Frames, and Address Translation

Paging splits a process into fixed-size pieces called pages. Each page carries a number, and that page number maps directly into a frame number. A frame is a fixed-size slot in physical memory, and the frame size always equals the page size. The two names never blur: the frame number always corresponds to physical memory, while the page number corresponds to the virtual (logical) address space — everything from the user's point of view. The CPU generates a logical address for every instruction fetch and every data access, and that logical address must be converted into a physical address before the memory can be touched for execution.

The mapping, or translation, between pages and frames is done by a page table: a table with one entry per page, where each entry stores the frame that currently holds that page. Whatever the number of pages a process has, those pages are placed into physical memory with the help of frames, and every lookup ends in a base-plus-offset calculation: take the frame number as a base, convert it into bytes by multiplying by the frame size, and add the offset — the distance inside the page — to reach the exact location.

An everyday picture helps: think of a textbook cut into equal chapters and a library shelf cut into equal slots. The chapters are the pages, the slots are the frames, and the page table is the index card that tells you which slot currently holds chapter 7. The analogy breaks in one place: the index card is printed once, while a page table is rewritten by the operating system every time a page moves to a different frame.

Visually, the setup has two columns. On the left, the process's logical address space is sliced into equal blocks labeled page 0, page 1, page 2, …; on the right, physical memory is sliced into equal frames labeled 0, 1, 2, …. Arrows leave each page and land on a different frame, and the arrow's destination is stored in the page table. Because pages and frames are the same size, the pieces fit together like blocks into matching holes, with no irregular gaps between them.

13.1.2 Worked Example: A Four-Page Process Mapped to Frames

The mapping is worth doing once slowly, in full, with real numbers.

13.1.3 Page Table Hardware and the TLB

Because the CPU translates an address on every single memory access, translation must be fast. To keep it fast, we add a small hardware cache called associative memory, or the translation look-aside buffer (TLB). The TLB stores pairs of page numbers and their frame numbers — it is a cache of page table entries. It is tiny: the entries typically range from a minimum of 64 to a maximum of 1024. When the CPU produces a logical address, the page number is looked up in the TLB first. If it is found — a TLB hit — the frame number comes with it, the offset is appended, and the physical address is ready. If the page number is not in the TLB — a TLB miss — the lookup falls through to the page table.

Why is the TLB needed at all? Because the page table always lives in main memory. To find an entry you need two registers: a base register that points to the start of the page table, and a page table length register (PTLR) that holds the size of the page table. To access one instruction or one piece of data you need two memory accesses: the first goes to the page table to fetch the frame number, the second goes to the frame itself to fetch the data or instruction. That doubling is the price of paging — and the TLB is the cure, because a hit replaces the first memory access with a fast cache lookup.

If the page is not in the page table either, it lives on secondary storage, and we must bring it in with a page replacement policy — the topic of Section 13.4. The hardware support needed for paging is exactly this: the base register, the length register, and the associative memory. The valid/invalid bit protects the table as well: before trusting an entry, the system checks whether the page is legal and present.

Real-world: the TLB is the hardware cache inside the processor that makes address translation fast; without it, every single memory access would be doubled by page-table lookups. The percentage of translations found in the TLB is called the hit ratio, and on real processors it is well above 95% — that is why paging costs so little in practice. The hit ratio is so important that modern designs use larger pages (2 MB or even 1 GB "huge pages") just to make each TLB entry cover more memory.

13.1.4 Page Size Trade-offs and Frame Allocation

The page size is usually 4 KB to 8 KB, with 4 KB being the standard on x86 systems. The choice of page size matters for three things: how much space is wasted to internal fragmentation, how many entries the page table needs, and how efficient disk I/O is. Paging is a form of dynamic relocation, and because pages and frames are fixed-size blocks, there is no external fragmentation — the gaps between allocations simply do not exist. The page size decides how much leftover space inside a page is wasted, which is internal fragmentation.

When to pick which: small pages fit processes with sparse memory use; large pages win when big sequential data dominates, because the I/O savings and the smaller tables outweigh the wasted space inside pages.

A frame table keeps track of which frames are allocated and which are free. When a new process arrives, it takes frames from the pool of free frames. Consider a process with four pages and five free frames. The pages are assigned to frames from the free pool: page 0 goes to frame 14, page 1 to frame 13, page 2 to frame 18, and page 3 to frame 20, leaving one frame free for other processes. The first thing to do after any allocation is to make the page table entry: page 0 now maps to frame 14, page 1 to 13, and so on. That entry is the only link the system uses later to translate addresses for that process — allocate the frame, then record the mapping, before anything else touches the page.

13.2 Worked Problem: How Many Bits in a Paging System

13.2.1 The Setup and the Formulas

The setup of the problem is simple and recurring. A paging system has:

• physical memory of $2^{32}$ bytes,
• a page size of $2^{10}$ bytes,
• a logical address space of $2^{16}$ pages, with each page of size $2^{10}$.

Two formulas do all the work. The first: the size of the logical address space equals the page size times the number of pages in the logical address space, and the number of bits in the logical address is the base-2 logarithm of that size. The second: the same idea applies to the physical address, only with different values — the physical address space is the number of frames times the frame size. Remember that the frame size always equals the page size.

13.2.2 All Five Answers Worked Out

The five questions chain together: each answer feeds the next — address space, then bits, then frames, then entries, then bits per entry.

13.2.3 Practice Question with Given Answers

A second problem of the same kind was shared with answers already given; you can try it later on your own and check. Work through the same five questions — logical address bits, frame bytes, physical address frame bits, page table entries, and bits per entry — using the same two formulas.

To make the pattern stick, try this self-check variant: a system with physical memory of $2^{36}$ bytes, a page size of $2^{12}$ bytes, and a logical address space of $2^{20}$ pages. Working the chain: $2^{12}\times 2^{20}=2^{32}$ → 32-bit logical address; frame size $=2^{12}$ → 12 bits per frame; $2^{36}/2^{12}=2^{24}$ frames → 24 frame bits and $36-24=12$ offset bits; $2^{20}$ page table entries; 24 bits per entry. Run the same five steps on the shared practice question and check every answer the same way.

13.3 Virtual Memory and Demand Paging

13.3.1 What Virtual Memory Is and Why We Need It

Virtual memory seems to exist, but really does not exist — that is the meaning of virtuality. It is a technique that allows the execution of processes that are not completely in memory. Physical memory size cannot be increased; whatever is there will only be there. Yet we can still run many processes, and the reason the degree of multiprogramming — the number of processes present in memory at any time — can be raised is exactly this technique.

Why go to virtual memory? Several motivations. Programs declare tables, arrays, and lists, and each process needs all of those allocated, so the memory needed can exceed what is present. The principle of locality (discussed in Section 13.6) means only part of a program is actively used at any moment. And unusual conditions must be handled by programs that need to be present in memory. The advantages follow: there is no constraint from the amount of physical memory available, because each program does not actually take that much memory and not all programs run at the same time; throughput and CPU utilization both increase; programs that are not necessary can be swapped out of memory to make room, and other programs can be brought in and made to work faster.

A theatre analogy captures the split: the act seems to have every prop it needs, but only the props currently on stage are in memory; the rest wait backstage in storage and are carried out only when a scene needs them. Mapping: the stage is physical memory, the storage room is the swap device, and the props are pages. The break point: hauling a prop from storage takes time — that is the page fault cost that Section 13.3.4 measures.

Inside the virtual address space, the data and the code occupy their regions, and the remaining space is left for the stack and the heap: the stack always grows down and the heap always grows up. They start at opposite ends of the address space and grow toward each other, which gives both room to grow without a fixed boundary.

Real-world: this is how every modern operating system lets programs bigger than the installed physical memory still run, and why adding processes raises utilization instead of exhausting memory. A browser with many open tabs is the everyday example — every tab runs with its own large virtual address space, while the physical frames are shared and only the pages in active use stay resident.

13.3.2 Demand Paging and the Lazy Swapper

Bringing in a page only when it is needed is demand paging, and it is done by a lazy swapper. The lazy swapper never swaps a page into memory unless that page is needed; the swapper used for this kind of paging is called the pager. When a page or a set of pages is not required, it is swapped out to secondary storage, and only the pages necessary for execution are brought from secondary storage into memory. That selective swapping is how virtual memory is implemented.

The advantages of demand paging: less I/O is needed, less memory is needed, responses are faster, and more users can be served at a time.

Consider the example from the lecture: page 7 corresponds to some data value H, and only three pages — A, C, F — are physically present. When page 7 is referenced, the page table entry has no frame and the bit is invalid, meaning page 7 is not in main memory. Execution can only continue if the page is brought in first.

13.3.3 What Happens on a Page Fault

A page fault starts in hardware and ends in the operating system. The full sequence, in order:

1. A reference is made to a page whose entry is invalid.
2. A trap is made to the operating system.
3. The operating system checks whether this is an invalid reference (an illegal address) and confirms the page is genuinely not in memory.
4. The system finds a free frame.
5. The page is brought in: a read request is issued from the disk to the free frame, and the request waits in the queue until it is serviced — the disk needs seek time and latency time before the transfer itself.
6. Once the free frame is found and the transfer completes, the page table is reset: the bit is set to valid and the frame number is placed in the entry.
7. The instruction is restarted.

Inside those steps, much happens that we do not need to worry about in detail: when the trap is made, the user registers save the state of the current process; the page fault is treated as an interrupt; the page reference is checked for legality and for presence on the disk; the disk request accounts for seek time and latency time; and while waiting, the CPU may be allocated to some other user — if the frame gets taken in the meantime, another interrupt is received, and after the I/O completes the registers are restored. This continues until a frame is present in memory and allocated to the page.

Two things matter for correctness: how to restart after a page fault, and how the instruction time is fetched during a page fault versus how data is fetched. An instruction that references several pages can fault partway through; the whole instruction must be restarted from its beginning, so the CPU must remember exactly where the faulting instruction started.

Real-world: the secondary storage used for this kind of paging is always known as the swap device — the swap space of a real system (a swap partition or swap file). Modern systems keep the swap on fast storage, but the operating system still works hard to keep the fault rate low, because every fault is a disk round trip.

13.3.4 Effective Access Time

To measure the performance of demand paging we use the page fault rate $p$, which lies between 0 and 1. If $p=0$, there is no page fault; if $p=1$, every reference faults. The effective access time (EAT) combines the two cases: with probability $(1-p)$ the page is in memory and costs one memory access, and with probability $p$ we pay the page fault service time:

$$EAT=(1-p)\cdot T_{memory}+p\cdot T_{fault}$$

where $T_{memory}$ is the memory access time and $T_{fault}$ is the page fault service time — the time to bring the missing page from the disk. The formula is an expected value: each reference pays the cheap memory access most of the time, and occasionally pays the expensive disk service instead.

13.4 Page Replacement Algorithms

13.4.1 Why We Need Page Replacement

A page can be brought into memory only if a free frame exists. When all frames are occupied, the system must find a victim page: some page in memory that is not actually needed at present, or will not be needed for a while, is swapped out to secondary storage, and the page we need is brought into its frame. This happens when there is no free frame at all, and the performance then depends on how many page faults occur: the fewer the faults, the better the performance. We want an algorithm that always results in the minimum number of page faults. A bad policy can even cause the same page to be swapped out and swapped in many times.

To reduce that overhead we can keep one more bit, the modified bit (or dirty bit). The dirty bit records whether a page has been modified since it was loaded into memory. When a page is selected for replacement, the system checks its dirty bit: if the bit is clear, the page is identical to the copy on disk, so it can be dropped without any write-back — one transfer saved. Only pages with the dirty bit set (read-write pages that were actually written to) must be written out before the frame is reused. Clean, read-only pages such as binary code are never written back at all. This can cut the replacement I/O roughly in half.

So demand paging requires two algorithms together: the frame allocation algorithm, which allocates the free frames among the processes, and the page replacement algorithm, which decides which pages are to be replaced. They are different jobs, and we always want the one with the lowest page fault rate. Evaluation is done by feeding a given reference string — the sequence of pages a process references — through the algorithm and counting the page faults.

13.4.2 FIFO and Belady's Anomaly

The first page replacement algorithm is first in, first out (FIFO): the page that came into memory first is the one chosen for replacement. It is the simplest scheme — a queue: new pages enter at the tail, and the victim is whatever sits at the head. Its cost is one pointer per reference and no search at all.

Now suppose four frames are used instead of three, and the same pages are placed in the same manner: the number of page faults rises to 10. That is surprising: adding a frame made the algorithm perform worse. More frames leading to more page faults is Belady's anomaly, named for the person who showed it. The graph of frames versus page faults climbs instead of falling; you can take a reference string and run the algorithm yourself to see the same shape.

Visually, plot the number of frames on the horizontal axis and the number of page faults on the vertical axis. For most algorithms the curve falls as frames increase; for FIFO on this string it dips to 9 faults at three frames and then rises to 10 at four — a bump in the middle of a curve that should be falling. That bump is Belady's anomaly in the shape of a graph.

13.4.3 Optimal Replacement

Optimal replacement says: replace the page that will not be used for the longest period of time. It thinks futuristic — it looks at the future and asks which page will not be needed for the longest time, picks that one as the victim, and replaces it.

The catch: the algorithm needs future knowledge of the reference string — which page we may need, and which page will not be used. In real systems that knowledge is not available, which is the problem with this algorithm; it serves as the ideal that other algorithms are measured against. No algorithm can beat optimal on a given reference string with a fixed number of frames, so it is the yardstick: if a new algorithm stays within a few percent of optimal, it is doing well.

13.4.4 LRU and Its Implementations

Least recently used (LRU) works from the past instead of the future: the page not used for the longest period of time so far is selected as the victim. The name says it — take out the one that has been idle longest. LRU is optimal looking backward: if the recent past is a good predictor of the near future, the page that was least useful recently is the page least likely to be needed next.

LRU can be implemented in several ways. With a counter (a clock): each page table entry gets a counter, and when a page is referenced the current clock value is copied into its counter; when a victim must be chosen, look at the counters and pick the page with the oldest value — the counter says when that page was last used. With a stack of page numbers: the stack keeps the pages ordered by recency of use, with the least recently used page at the bottom; when a page is referenced it is moved to the top, which requires double pointers and pointer updates; the victim is simply the page at the bottom, the one that came first and was not used recently. Or with a reference bit: each page carries a bit, initially zero; whenever a page is referenced the bit is set to one; when a victim is needed, pages whose bit is zero are candidates, and a page with the bit set to one is not considered.

The cost of true LRU is real: the counters or the stack must be updated on every memory reference. Doing that in software would slow every reference by a factor of about ten, so true LRU needs hardware support; systems without that support fall back to reference-bit approximations such as the second chance algorithm below.

13.4.5 Second Chance and Counting Algorithms

The reference bit idea grows into the second chance algorithm. When a victim must be selected, walk through the pages and look at each reference bit. If the bit is zero, replace that page. If the bit is one, give the page a second chance: clear the bit to zero and move on to the next page. A recently referenced page survives one more round; only if it stays untouched will it be replaced on a later pass.

The standard implementation is a circular queue with a pointer — the clock algorithm: the pointer advances until it finds a page with a zero reference bit, clearing the bits of every page it passes. If all bits are set, the pointer makes a full circuit, clearing every bit and giving every page a second chance — and the algorithm then degenerates into plain FIFO. A further refinement pairs the reference bit with the modify bit, preferring clean pages (0,0) over modified ones, but the core idea stays the same: one round of grace for recently used pages.

Beyond LRU and its variations there are counting algorithms. Keep a count of how many references have been made to each page. LFU (least frequently used) always replaces the page with the smallest count; MFU (most frequently used) replaces the page with the largest count. If the count is very small, the page is least frequently used; a large count means most frequently used. These are not common algorithms in practice: LFU keeps pages that were heavily used long ago but are now dead weight, and MFU rests on the shaky argument that a small count means a page was just brought in and has yet to prove itself.

13.4.6 Choosing a Replacement Algorithm

Two properties matter when comparing algorithms. FIFO can exhibit Belady's anomaly — more frames, more faults. Optimal and LRU do not exhibit the anomaly: with either of them, increasing the number of free frames never increases the page faults. That is their beauty. The reason is structural: optimal and LRU are stack algorithms — the set of pages they keep with $n$ frames is always a subset of the set they keep with $n+1$ frames — so more frames only ever add pages, never push useful ones out. FIFO has no such property.

Among all the algorithms, optimal is far better — but it needs the future, so LRU (with past knowledge) is the practical stand-in. You can verify this yourself: take the example reference strings, assume three frames in one run and five frames in another, work out the faults for each algorithm, and make a comparison — the counts confirm both the ordering and the anomaly immunity.

13.5 Segmentation

13.5.1 The User's View of Memory

Segmentation is another memory management scheme, and it supports the user view of memory: as a user, a program is always a collection of segments. A segment can be a main program, a procedure, a method, a small module — whatever you consider — and even variables or a block of information count as a segment. The compiler is the one that generates these segments, and the loader assigns a number to each and every segment. Each segment can have its own size, so variable sizes are fine; there is no required order in which segments are placed, and none is needed.

Because the whole logical address space is built from these segments, an address must always be specified in two parts: the segment number (or name) followed by the segment offset. Together they form the logical address. To see the logical view, address it with the segment number and the offset.

An everyday picture: a multi-drawer cabinet. Each drawer is a segment — drawers hold different amounts and are labeled with different contents; the address of any item is (drawer number, position inside the drawer). The analogy breaks in one place: the drawers in the cabinet sit side by side, while segments in memory can be scattered anywhere, and their sizes are set by the compiler, not by the cabinet maker.

The comparison with paging shows what segmentation buys and what it costs:

When to pick which: paging for simplicity and no external fragmentation; segmentation when the program's structure should drive memory layout and sharing matters.

13.5.2 The Segment Table and Address Translation

Where paging had a page table, segmentation has a segment table. The segment table has two entries per segment: the base and the limit. The base is the starting physical address where the segment is present in memory; the limit is the length of each segment. Two registers maintain these: the segment table base register (STBR) points to the location of the segment table in memory, and the segment table length register (STLR) specifies how many segments are in memory. A segment number is legal only when it is less than the value in the length register; the length register sets the legal range for segment numbers.

The base and limit pair is a protection mechanism: a process can only ever touch memory inside its own segments, and any address beyond a segment's limit is stopped at the table, before it reaches memory. The offset $d$ is a distance from the segment's start, so $0\le d<\text{limit}$ must hold.

13.5.3 Worked Example: Checking Legal Segment Addresses

The lecture works the classic five-address example; the segment table it is taken from (the textbook exercise) is the one below.

One note on the numbers: the limits spoken in the lecture were partly garbled (segments 0–4 were read at different points as roughly 600, 40, 100, 580, and 96). The table above is the canonical one from the textbook exercise that these exact addresses come from. The verdicts agree with the lecture for (0, 430), (1, 10), (2, 500), and (3, 400) — and for (4, 112) the lecture's garbled limit of 96 would reject the reference, while the textbook limit of 1000 accepts it at 4812. Both versions share the identical rule: check offset < limit before adding the base, and an address that fails the check raises a trap.

The rule to carry away: always verify offset < limit first; only a valid offset can be added to the base to form the physical address.

13.6 Thrashing

13.6.1 What Thrashing Is

If a process does not have enough pages, its page fault rate stays high. Imagine a memory holding some pages, but the process keeps referring to pages that are not in memory at all: every page reference is a fault, every fault forces a replacement of an existing frame, and then the next reference faults again. Each and every reference requires swapping out a page and bringing in another, so most of the time the system spends itself on replacement instead of execution. That condition — a process busy always swapping pages in and out — is thrashing, and it must not occur. Its cost is a direct drop in CPU utilization: the CPU is there and ready to execute pages, but the pages are never there when needed.

An everyday picture: a chef whose ingredient bins are too small for the dish being cooked. Every dish forces a trip to the cold storage to swap ingredients in and out of the bins; the chef spends the evening walking, not cooking. The mapping: the chef is the CPU, the bins are the frames, and cold storage is the swap device. The break point: the chef could simply use bigger bins, but a process's reference pattern is fixed by the program — the only fix is giving the process enough frames for the pages it is actually using.

13.6.2 Degree of Multiprogramming and CPU Utilization

The degree of multiprogramming and CPU utilization are directly proportional up to a point. As more processes are placed in memory, the CPU stays busy with some work and utilization rises. But beyond a certain point, the number of pages present in memory becomes too few, thrashing begins, and utilization falls instead of rising. The curve goes up, peaks, and turns down; the peak is the thrashing point. Increasing the degree of multiprogramming past that point is counterproductive — the CPU has less to do, not more.

Visually, plot the degree of multiprogramming on the horizontal axis and CPU utilization on the vertical axis. The curve climbs steeply at first as more processes keep the CPU busy, flattens as memory fills, and then falls away on the right as thrashing takes over. The landmark is the peak: the best degree of multiprogramming sits at the top of the curve, where utilization is highest and no process is starved of frames.

13.6.3 Locality and the Working Set Model

Why does thrashing happen? The explanation comes from the locality model. A locality is the set of pages that are actively used together at a time. The process moves through localities: some pages are referenced together, then the process migrates to another group, and localities may even overlap. Thrashing occurs when the total size of the working locality is larger than the total memory size — then every time one page is brought in, another must be swapped out, and the faulting never stops.

Demand paging can be made to work with the locality model. One way to limit thrashing is local replacement — the priority replacement algorithm built on the working set model. With the working set model, keep a window of references: the pages referenced within the current window are the working set, and they get priority — they will not be swapped out. Pages referenced only outside the window (4, 5, 6, whatever is not in the window) are the ones considered for replacement. The window slides as references accumulate, so the protected set tracks where the process currently is.

The working set idea formalizes cleanly: pick a window size $\Delta$ (say, the last $\Delta =10$ references); the working set at any moment is the set of distinct pages referenced inside that window. Each process then has a working set size $WS{S}_i$, and the total frame demand is

$$D=\sum _{i}WS{S}_i$$

If the total demand $D$ exceeds the number of available frames $m$, some process cannot keep its working set resident — and thrashing follows. The fix is to give each process as many frames as its working set needs, and to suspend a process (swap it out entirely) when the sum of working set sizes exceeds memory. Choosing $\Delta$ matters: too small a window misses part of the locality, too large a window overlaps several localities, and an infinite window covers every page the process ever touched.

The course textbook covers the local and priority replacement methods in detail; for the concept itself, the summary above is enough — and the page replacement algorithms, together with the paging problems, are the important material of this topic.

Real-world: the working set idea is embedded in real systems — Windows tracks a per-process working set with minimum and maximum sizes and trims pages when memory tightens, and Linux approximates the same idea with reference-bit clocks and page-fault-frequency control. Servers and databases tune these knobs so that interactive processes keep their hot pages resident while batch work is suspended.

13.7 OS Simulator: Running the Assignment Simulations

13.7.1 Q&A: How to Run the Simulations

One of the assignment problems (question 15) asks for six programs to be run, and a student raised a doubt about it. The resolution is a straight procedure: the simulator does the work once each program is loaded, and the skill being tested is reading the snapshots and the process view afterward.

The procedure, step by step:

1. Compile each of the six programs on its own, one at a time.
2. Load the compiled program into the simulator — copy and paste it, select it, compile it in the simulator, and load it; the simulator picks it up automatically.
3. Select the scheduling algorithm — for round robin, make sure round robin is selected before executing.
4. Execute the program.
5. Take a snapshot of the run.
6. Suspend the execution for some time.
7. Open the process view and check the resources shown there.
8. Explain what you see, one step after another, and use the snapshots as evidence, following the questions given.

13.7.2 Study Resources

Reference PDFs were shared for each topic — deadlock, synchronization, threads, and scheduling — and the questions for the assignment are there too. Whatever is in those reference PDFs is the overall view to follow. The OS simulator itself is the tool to practice on: run the programs, take snapshots, suspend execution, and inspect the process view and the resources. The course textbook covers the underlying policies — scheduling, synchronization, and deadlock — in depth, so use it to understand the why behind each snapshot the simulator shows.

Exam Guidance Summary

• Page replacement algorithms are very important. Be ready to work reference strings by hand for FIFO, optimal, and LRU, and to count page faults. Know Belady's anomaly: FIFO can produce more faults with more frames, while optimal and LRU cannot. Practice on the lecture strings — 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5 (9, 10, 6, and 8 faults for FIFO-3, FIFO-4, optimal-4, and LRU-4) and 7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, 1, 2, 0, 1, 7, 0, 1 (9 faults for optimal-3).
• Paging numerical problems are important. The five-question pattern (bits in the logical address, bytes in a frame, bits that specify the frame, page table entries, bits per entry) is core material; work through the practice question with the given answers and the shared practice examples. Remember the chain: address space → bits → frames → entries → bits per entry.
• The important topics of this material are paging and the problems worked for it, plus the page replacement algorithms; solve the example problems on your own and check your answers. Also review the EAT formula from Section 13.3 (a 0.1% fault rate still dominates the effective access time) and the offset < limit rule from Section 13.5, since both are worked-example favorites.
• Assignment work: use the OS simulator — compile each program separately, load it, select the scheduling algorithm (round robin, for example), execute, take snapshots, suspend, and inspect resources in the process view — and support the results with explanations.

Key Industry Applications

• Real-world: the TLB is the hardware cache inside the processor that makes address translation fast; without it every memory access would cost two trips. Every modern CPU — x86, ARM, RISC-V — ships a TLB, and designs such as x86 huge pages (2 MB or 1 GB) exist largely to widen the TLB's reach.
• Real-world: virtual memory is how modern operating systems run programs that are bigger than physical memory and how they raise the degree of multiprogramming — every desktop browser, database server, and container runtime depends on it.
• Real-world: the secondary storage used for paging is known as the swap device — the swap space of a real system (a swap partition or swap file on Linux, the page file on Windows).
• Real-world: the OS simulator is a practical tool for exercising scheduling and resource-management policies end to end, letting students watch round robin, snapshots, and the process view in action before meeting the policies on a real system.