Skip to content

Latest commit

 

History

3 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Design, Implementation, and Evaluation of an MMU Simulator

Project Overview

This project features a modular simulation of a Memory Management Unit (MMU) designed to evaluate theoretical operating system concepts in a practical environment. Key performance metrics—including Effective Access Time (EAT), Translation Lookaside Buffer (TLB) Hit Rate, and Page Fault Penalties—are meticulously calculated. The simulation analyzes FIFO and LRU replacement algorithms across Locality, Random, and Thrashing access patterns. Furthermore, it highlights how Write-Back policies and Dirty Bit management can act as severe performance bottlenecks in diverse workloads.

System Architecture

The simulator is built using an object-oriented, modular approach:

  • Virtual Address: Decomposes a virtual address into a Virtual Page Number (VPN) and offset.
  • PageTable: Models a multi-level page table tree utilizing a Lazy Allocation approach to prevent memory waste.
  • TLB Simulation: Maintains a limited capacity of 16 entries, supporting both FIFO and LRU replacement mechanisms.
  • Frame Allocator: Restricts physical memory to just 16 frames to swiftly expose page fault phenomena.
  • Simulator Core: Orchestrates the entire memory access lifecycle, logs system statistics, and dynamically computes the EAT.

Simulation Results & Performance Metrics

The system was evaluated using 10,000-instruction traces, assuming specific hardware costs: TLB access (1 cycle), Page Table Walk (100 cycles/level), and Page Fault to mechanical disk (1,000,000 cycles).

Scenario Policy TLB Hit Rate Page Faults Effective Access Time (EAT)
Locality FIFO 91.83% 817 146,617.26 cycles
Locality LRU 91.86% 814 146,017.20 cycles
Random FIFO 5.90% 9,410 1,237,088.26 cycles
Random LRU 5.88% 9,412 1,237,288.30 cycles
  • Locality vs. Random: LRU outperforms FIFO in Locality scenarios because real-world applications frequently revisit recently accessed data; conversely, both algorithms fail equally during purely random accesses.

Write-Back Policy & Dirty Bit Analysis

Replacing a "Dirty" page requires writing changes back to the disk, doubling the page fault penalty to a staggering 2,000,000 cycles.

  • Read-Heavy (10% Writes): Generated 812 page faults, with only 440 requiring Write-Back operations (EAT: 125,217.16 cycles).
  • Write-Heavy (80% Writes): Triggered 868 page faults, forcing 826 heavy Write-Back operations and causing massive performance degradation (EAT: 169,418.27 cycles).
  • Conclusion: Secondary memory write operations create severe bottlenecks; modern OS designs prioritize evicting clean pages over dirty ones to mitigate exponentially wasted cycles.

About

No description or website provided.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages