CS370

HW 5

TLB and Advanced Paging

Theory:
Note: Homework this week will be quite theory heavy as we understand how Translation Lookaside
Buffers and Advanced Paging works! Next week will be more exercise heavy as we learn more about
swapping mechanisms.

Q1. Why do we need a Translation-Lookaside Buffer (TLB) for virtual-to-physical address

translations when we have a page table available in memory for address translation?

Ans: Page tables are slow. Before translating the virtual-to-physical address, the page table entry
from the process’s page table has to be fetched. TLB is the hardware solution that makes translation
much faster and more efficient. A TLB is essentially a cache that stores the recent translations of
virtual memory to physical memory, which then helps avoid the extra memory access needed for
translation.

Q2. What is the difference (if any) between the valid bit in the page table and the TLB?

Ans: The valid bit of TLB is not the same as one in a page table. In a page table, when a page-table
entry (PTE) is marked invalid, it means that the page has not been allocated by the process, and
should not be accessed by a correctly-working program. The usual response when an invalid page is
accessed is to trap to the OS, which will respond by killing the process.

A TLB valid bit, in contrast, simply refers to whether a TLB entry has a valid translation within it.
When a system boots, for example, a common initial state for each TLB entry is to be set to invalid,
because no address translations are yet cached there. Once programs start running and accessing
their virtual address spaces, the TLB is slowly populated, and thus valid entries soon fill the TLB. By
initially setting all TLB entries to invalid, the system can ensure that the about-to-be-run process
does not accidentally use a virtual-to-physical translation from a previous process.

While both bits serve the same concept of validity, the TLB's valid bit checks the status of the cached
translation in the TLB cache, whereas the page table's valid bit checks the status of the translation in
the main memory's page table.

1
 CS370

Q3. What is the advantage of using multi-level page tables? Do we need to go beyond two levels in
multi-level page tables? Why?

Ans: The multi-level table only allocates page-table space in proportion to the amount of address
space you are using; thus it is generally compact and supports sparse address spaces. Also, if
carefully constructed, each portion of the page table fits neatly within a page, making it easier to
manage memory; the OS can simply grab the next free page when it needs to allocate or grow a page
table. Compare this to a simple (non-paged) linear page table , which is just an array of PTEs
indexed by VPN - with such a structure, the entire linear page table must reside contiguously in
physical memory. For a large page table (say 4MB), finding such a large chunk of unused contiguous
free physical memory can be quite a challenge. With a multi-level structure, we add a level of
indirection through use of the page directory, which points to pieces of the page table; that
indirection allows us to place page-table pages wherever we would like in physical memory.

By constructing a multi-level page table, our goal is to make each piece of the page table fit within a
single page. So, if the page directory becomes too big we will be dealing with the same problem of a
large page table. So, instead of growing the page directory horizontally, we add depth to the page
table, hence reducing the requirement of big pages in memory. Additional levels allow for a
finer-grained distribution of memory, better scalability, and a more efficient allocation of page
tables, making them well-suited for extremely large address spaces.

Q4. In a system with limited physical memory, a multi-level page table structure is implemented to
efficiently manage large virtual address spaces. What would be the advantages and trade-offs of
using multi-level page tables in such a memory-constrained environment?

Ans: As we know, implementing a multi-level page table structure provides advantages in terms of
reduced memory usage, scalability for large address spaces, and efficient management of sparse
address spaces.

However, there are trade-offs, including increased address translation time due to the need to
traverse multiple levels of page tables, complexity in implementation and management, potential
fragmentation in physical memory, and limitations on consecutive memory allocation. These
trade-offs make multi-level page tables suitable for systems prioritizing memory efficiency over fast
address translation.

Q5. During a context switch, the TLB is typically flushed to ensure that the new process's
virtual-to-physical mappings are used. Why do we have to do this, and what would happen if we
didn’t?

Ans: Flushing the TLB during a context switch is necessary to maintain data integrity and process
isolation. When a context switch occurs, the new process may have a different set of

2
 CS370

virtual-to-physical address mappings than the previous process. This means that a certain virtual
address may have different physical mappings, but the hardware can’t distinguish which entry is
meant for which process. If we did not flush the TLB, it would result in the continued use of the old
process's mappings, leading to incorrect memory accesses and data corruption. This also poses
security risks, as processes will start accessing other processes' information (which may be
sensitive information).

Flushing the TLB is a vital mechanism to guarantee that each process operates with its own set of
accurate and secure virtual-to-physical mappings, despite the context switches. Although it
introduces a slight performance overhead as we would need to reload TLB entries for the new
process, the benefits in terms of data integrity and security far outweigh this cost.

Exercises:

Q1. Assume that in a certain computer, the virtual addresses are 64 bits long and the physical
addresses are 48 bits long. The memory is word addressable. The page size is 8 kB and the word
size is 4 bytes. The Translation Look-aside Buffer (TLB) in the address translation path has 128
valid entries. How many distinct virtual addresses can be translated at most without any TLB miss?

Ans:
The number of words in a page can be calculated by page size/ word size
= 8 kB / 4 B
= 2048 (or 2 B)
11
=2

We know the TLB can hold 128 entries, therefore it can translate:
= 128 * number of words in page
11
= 128 * 2 addresses without any TLB miss

Q2. Consider a virtual memory system with physical memory of 8GB, a page size of 8KB, and 46-bit
virtual address. Assume every page table exactly fits into a single page. If page table entry size is 4B,
then how many levels of page tables would be required.

Ans:
13
Given a page size of 8KB = 2 B
43
A 46-bit virtual address = 2 B
2
Page table entry is 4B = 2 B

3
 CS370

Calculating the number of page table entries:

= virtual address space size / page size
46 13
=2 B/2 B
33
=2 B

Calculating the size of the page table:

= number of entries in the page table * size of the page table entry
33 2
=2 * 2 B
35
=2 B

Calculating the number of levels: Remember our goal in constructing a multi-level page table: to
make each piece of the page table fit within a single page!
(divide until the size of page table is equal to size of a page, this will give you number of levels)

● Number of page tables in first level:

35 13 22
= 2 B / 2 B =2 pages
Thus the page table size (second level) is
22 2 24
= 2 B * 2 B =2 B
24 13
● 2 >2 so we add another level:
24 13 11
= 2 B / 2 B =2 pages
Thus the page table size (third level) is
11 2 13
=2 B * 2 B =2 B

Size of the page table is now equal to the size of a single page hence no further divisions are needed!
Required number of levels is 3.

Q3. Have a look at the following diagram which models a small TLB (3 entries) and a reference row
depicting the entries to be accessed.

Reference Row:

6 2 3 6 4 0 4 8 9 0 3

If the TLB starts empty, what would be in the TLB when 0 (both cases) needs to be accessed?
Consider that we are using the LRU (Least Recently Used) replacement policy.

a) Before accessing 0 (the first one)

6 4 3

4
 CS370

Then we would remove 3 as it was least recently accessed:

6 4 0

b) Before accessing 0 (the second one)

8 4 9

Then we would remove 4 as it was least recently accessed:

8 0 9

Try working this out by hand and map the entries as they enter and are swapped out of the TLB!