Effective access time

• 👨‍🏫 associative memory: $\approx$ cache!
• associative lookup: $\epsilon$ time unit
  • usually: $<10\%$ of memory access time
• hit ratio: $\alpha$
• then effective access time (EAT): memory access time normalized to 1 $$\begin{array}{rl}\text{EAT}& =(1+\epsilon )\alpha +(2+\epsilon )(1-\alpha )\\ & =2+\epsilon -\alpha \\ \text{avg. Access Time}& =(T_{asso}+T_{TLB})\alpha +(T_{asso}+T_{TLB}+T_{mem})(1-\alpha )\\ & =2+\epsilon -\alpha \end{array}$$
  • e.g. $\alpha =99\%;\epsilon =20\text{ ns};T_{mem}=100\text{ ns}$
  • $\text{EAT}=0.99\times 120+0.01\times 220=121\text{ ns}$

Memory protection

• memory protection: done by protections bits associated w/ each frame
• usually kept in page table
  • one bit: define a page to be read-write / read-only
  • or: add more bit to indicate execute-only
• valid-invalid bit attached to each entry as well
  • valid: indicating a associated page is in process's logical address space
  • invalid: indicating a associated page is not in process's logical address space
  • OS: sets bit for each page to allow / disallow access to page
• any violations: result in a trap
  • e.g. within 14-bit address space, program uses address $0-10468$ w/ page size: $2\text{ KB}=2^{11}$
    • 8 pages
    • pages 0-5: valid
    • pages 6-7: invalid
• process: rarely uses all address range
  • often: some pages remain almost blank
  • creating a page table w/ every page in address range: waste of resource
    • most entries: being empty yet taking up memory space
  • 👨‍🏫 use page-table length register (PTLR) to indicate the size of the page

Shared pages

• shared code
• private code & data

Example: Intel x86 page table entry

• page table entry (PTE): entries of page table
  • w/ permission bits: valid, read-only, read-write, write-only
• e.g. Intel x86 architecture PTE
  • address: intel x86 architecture PTE
  • intermediate page tables: called directories
• 
• explanations
  • P
  • no need to write-back to memory
• 👨‍🏫 no. of frame: not necessarily same as no. of pages
  • more on virtual memory!

Structure of the page table

• further work

• problem:
  • page table: 4 MB = 1000 pages
    • cannot fit in a single frame!
    • kep requesting: must be kept track of
• hierarchical paging
• hashed page table

Hierarchical paging

• break up logical address space: into multiple page tables
• two-level / hierarchical page table: simply paging page table
• 👨‍🏫 idea: let "part" of page table fit into one page
• 
• assumptions
  • 32-bit machine w/ 4K page size
  • page no.: 20 bits
  • page offset: 12 bits
• to page the page table: further divide the page number
  • 10-bit page offset $P_2$: 10 bits if PTE occupies 4 bytes
    • ensures: each inner page table: stored within 1 frame / page
  • 10-bit page offset $P_1$: PTE also occupying 4 bytes
    • no. of bits in $P_1$: cannot be more than 10
  • 4K = 4 (= 32 bits) * 2^{10} entries
• diagram
  • 
    • $p_1$:$outerpagetable$
• penalty: performance from multiple memory access
  • 

Hashed page table

• common in address space: > 32 bits
  • as hierarchical: grows too quickly
• page no.: hashed into a page table
  • page table: containing chain of elements hashing into same location
    • 👨‍🎓 linked list!
    • 👨‍🏫 will appear again!
• each element

Example: 32 and 64-bit architecture

• dominant industry chips
  • 16-bit Intel 8086 (late 1970s) 8088: used in original IBM PC
• Pentium CPU: 32 bits, aka IA-32 architecture
  • supporting: both segmentation & paging
  • CPU: generates
• current Intel CPU: 64-bit and called IA-64 architecture
• many variations exist, but only main ideas are covered here

Example: Intel IA-32 architecture

• supports: both segmentation & segmentation w/ paging
  • each
• logical address: generate by CPU

Intel IA-32 segmentation

• 
• hardware diagram
  • 
• address conversion diagram
• 53-54 bits: used for total of 64 bits

Example: ARM architecture

• dominant mobile platform chip
  • modern, energy efficient, 32-bit CPU
• 4 KB & 16 KB pages
• two levels of TLBs

Background

• 👨‍🏫 you don't need to load entire program data on memory
  • error code / unusual routines: rarely occurring & almost never executed
    • 👨‍🏫 70% of the system programming!
  • data structures like arrays / tables: often allocated more memory than need
  • certain option / features of program: used rarely
• even if entire program is needed: might not be for entire running time
• consider: executing partially-loaded programs
  • programs: no longer constrained by limits of physical memory
    • programs: can be written w/ extremely large VM address
  • each user program: take less physical memory
  • more programs can be run simultaneously!
  • increasing CPU utilization, degree of multiprogramming, and throughput
  • less IO needed to load & swap user program into physical memory
    • each user program: runs faster
• ❓ what if we call fork() within VM?
• virtual memory: separation of user logical memory (aka address space) from physical memory
  • more program can be run concurrently
  • less IO for load / swap processing
• VM: implemented via:
  • demand paging / segmentation: similar in principle
    • difference: fixed-size and variable-size frame/page/segment

Virtual-address space