6a:T444,To understand why frame allocation is challenging, we must first appreciate the fundamental asymmetry between virtual and physical memory. **Virtual memory illusion:** Virtual memory creates a powerful abstraction. Each process believes it has access to a vast, contiguous address space—potentially spanning terabytes on 64-bit systems. From the process's perspective, memory is abundant and private. It can allocate, access, and manipulate addresses without concern for other processes or the physical hardware. **Physical memory reality:** Beneath this illusion, physical memory (RAM) is a fixed resource. A system with 16 GB of RAM has exactly 16 GB—no more, no less. If pages are 4 KB, that translates to approximately 4 million frames. This sounds like a lot, but consider: - The operating system kernel requires a significant portion (often 1-4 GB or more) - Device drivers and I/O buffers consume frames - Each running process needs frames for code, data, heap, and stack - File system caches and buffers require frames - Memory-mapped files and shared libraries occupy frames6b:T4a5,Before allocating frames to processes, the operating system must determine how many frames are actually available for allocation. This is not simply the total RAM divided by page size—several categories of memory are reserved or unavailable. **Total frames calculation:** ``` Total Frames = Physical RAM Size / Page Size = 16 GB / 4 KB = 16 × 2³⁰ bytes / 4 × 2¹⁰ bytes = 4 × 2²⁰ frames = 4,194,304 frames ``` **Reserved frames:** Not all frames are available for user process allocation: 1. **Kernel memory:** The kernel's code, data structures, and buffers are typically non-pageable (always resident) and occupy a fixed portion of physical memory. 2. **Hardware reservations:** Some memory addresses are mapped to hardware devices (memory-mapped I/O), firmware tables (BIOS/UEFI), or reserved by the hardware for specific purposes. 3. **Kernel structures:** Page tables themselves consume memory. For each process, representing its virtual address space requires frames for page table entries. 4. **DMA buffers:** Direct Memory Access buffers must reside in specific memory regions accessible by hardware devices.6c:Ta2e,/* * Frame Availability Calculation * * This demonstrates how an OS calculates frames available * for user process allocation. */ #include #include #define PAGE_SIZE 4096 // 4 KB pages #define GB (1UL << 30) #define MB (1UL << 20) typedef struct { uint64_t total_ram; uint64_t reserved_hardware; // BIOS, MMIO regions uint64_t kernel_resident; // Kernel code + data uint64_t kernel_structures; // Page tables, slab caches uint64_t dma_reserved; // DMA buffers uint64_t page_cache_minimum; // Min for file caching } MemoryPartition; typedef struct { uint64_t total_frames; uint64_t reserved_frames; uint64_t allocatable_frames; uint64_t free_list_frames; // Currently free } FrameStatistics; FrameStatistics calculate_frame_availability(MemoryPartition *mp) { FrameStatistics stats; // Total frames from total RAM stats.total_frames = mp->total_ram / PAGE_SIZE; // Sum all reserved memory uint64_t reserved_bytes = mp->reserved_hardware + mp->kernel_resident + mp->kernel_structures + mp->dma_reserved + mp->page_cache_minimum; stats.reserved_frames = (reserved_bytes + PAGE_SIZE - 1) / PAGE_SIZE; // Frames available for user process allocation stats.allocatable_frames = stats.total_frames - stats.reserved_frames; // Free frames would be tracked dynamically stats.free_list_frames = 0; // Placeholder return stats; } void print_statistics(FrameStatistics *stats) { printf(" Frame Allocation Statistics: "); printf("================================= "); printf("Total Frames: %lu ", stats->total_frames); printf("Reserved Frames: %lu ", stats->reserved_frames); printf("Allocatable: %lu ", stats->allocatable_frames); printf(" "); printf("Allocatable Memory: %.2f GB ", (double)stats->allocatable_frames * PAGE_SIZE / GB); } /* * Example for a 16 GB system: * * Total RAM: 16 GB * Hardware Reserved: 256 MB (BIOS, MMIO) * Kernel Resident: 512 MB (kernel code/data) * Kernel Structures: 768 MB (page tables, slabs) * DMA Reserved: 128 MB (device buffers) * Page Cache Min: 512 MB (ensure file I/O works) * --------------------- * Reserved Total: ~2.2 GB * Allocatable: ~13.8 GB * * This ~13.8 GB is what can be distributed among user processes. */6d:T4ea,Frame allocation is fundamentally a **resource multiplexing** problem. Limited physical frames must be shared among multiple competing processes, each with its own memory requirements and access patterns. **Why multiplexing is hard:** Unlike CPU scheduling, where time can be sliced in small increments and shared rapidly, memory frames cannot be so easily multiplexed: 1. **Switching cost:** Changing which process uses a frame is expensive—it requires disk I/O to save the old page and load the new one. This is orders of magnitude slower than a context switch. 2. **Locality requirements:** Processes don't access memory randomly. They exhibit **locality of reference**, accessing small subsets of their address space intensively. A process needs a certain number of frames to hold its working set; fewer frames cause constant page faults. 3. **Minimum thresholds:** Below a certain number of frames, a process cannot make forward progress. Each instruction might require multiple pages (instruction page, data page, stack page), creating a hard minimum. 4. **Non-preemptible during access:** Once a page is being accessed, it cannot be immediately reclaimed. The process may be mid-instruction, requiring the page until the instruction completes.6e:T4b1,To build intuition about limited frames, let's examine several scenarios that illustrate how scarcity manifests in real systems. **Scenario 1: Single large process** A scientific computing application attempts to process a 20 GB dataset on a system with 16 GB RAM. Even with all frames allocated to this one process, it cannot fit its entire working set in memory. The OS must: - Page out portions of the dataset not currently being processed - Manage I/O scheduling to minimize disk seeks - Hopefully the algorithm exhibits locality, accessing data in predictable patterns **Scenario 2: Many small processes** A web server spawns 100 worker processes, each requiring 200 MB for optimal operation. Total demand: 20 GB. With 16 GB RAM: - Each process could get ~160 MB (80% of optimal) - Marginal processes might trigger page faults - Under load, some workers might thrash **Scenario 3: Mixed workload** A desktop system runs: - Browser: 4 GB - IDE: 2 GB - Database: 3 GB - Various utilities: 1 GB - OS overhead: 2 GB - Total: 12 GB on 16 GB system This seems fine until the user opens a large file in the IDE, triggering additional memory demand that pushes the system into memory pressure.6f:T10cb,/* * Frame Scarcity Simulation * * This simulation demonstrates how the operating system * must cope with frame scarcity across multiple processes. */ #include #include #define MAX_PROCESSES 10 #define TOTAL_FRAMES 1000 // Simulated available frames typedef struct { int pid; int requested_frames; // What process wants int minimum_frames; // Below this: cannot run int optimal_frames; // For full efficiency int allocated_frames; // What it actually gets double efficiency; // Performance fraction } ProcessMemory; /* * Calculate efficiency based on allocated vs needed frames. * Models the non-linear degradation of insufficient memory. */ double calculate_efficiency(int allocated, int minimum, int optimal) { if (allocated < minimum) { return 0.0; // Cannot make progress } if (allocated >= optimal) { return 1.0; // Full efficiency } // Non-linear model: efficiency drops sharply as we approach minimum // This models the "cliff effect" of memory pressure double range = optimal - minimum; double above_min = allocated - minimum; double ratio = above_min / range; // Quadratic falloff - more realistic than linear return ratio * ratio; } void simulate_allocation(ProcessMemory procs[], int n, int strategy) { int remaining = TOTAL_FRAMES; printf(" === Allocation Strategy: %s === ", strategy == 0 ? "Equal" : strategy == 1 ? "Proportional" : "Priority"); // Calculate total demand int total_requested = 0; int total_minimum = 0; for (int i = 0; i < n; i++) { total_requested += procs[i].requested_frames; total_minimum += procs[i].minimum_frames; } printf("Total requested: %d frames ", total_requested); printf("Total minimum: %d frames ", total_minimum); printf("Available: %d frames ", TOTAL_FRAMES); if (total_minimum > TOTAL_FRAMES) { printf("WARNING: Cannot satisfy minimum requirements! "); } // Perform allocation based on strategy int allocated_sum = 0; for (int i = 0; i < n; i++) { switch (strategy) { case 0: // Equal allocation procs[i].allocated_frames = TOTAL_FRAMES / n; break; case 1: // Proportional to request procs[i].allocated_frames = (procs[i].requested_frames * TOTAL_FRAMES) / total_requested; break; case 2: // Ensure minimum, then distribute rest procs[i].allocated_frames = procs[i].minimum_frames; break; } allocated_sum += procs[i].allocated_frames; } // Strategy 2: distribute remaining proportionally if (strategy == 2) { int remaining_frames = TOTAL_FRAMES - allocated_sum; for (int i = 0; i < n; i++) { int extra_wanted = procs[i].optimal_frames - procs[i].minimum_frames; int total_extra = total_requested - total_minimum; if (total_extra > 0) { procs[i].allocated_frames += (extra_wanted * remaining_frames) / total_extra; } } } // Calculate efficiencies and print results printf(" %-5s %-8s %-8s %-8s %-8s %-10s ", "PID", "Min", "Optimal", "Request", "Alloc", "Efficiency"); printf("------------------------------------------------- "); double total_efficiency = 0; for (int i = 0; i < n; i++) { procs[i].efficiency = calculate_efficiency( procs[i].allocated_frames, procs[i].minimum_frames, procs[i].optimal_frames ); printf("%-5d %-8d %-8d %-8d %-8d %.2f%% ", procs[i].pid, procs[i].minimum_frames, procs[i].optimal_frames, procs[i].requested_frames, procs[i].allocated_frames, procs[i].efficiency * 100); total_efficiency += procs[i].efficiency; } printf("------------------------------------------------- "); printf("Average Efficiency: %.2f%% ", (total_efficiency / n) * 100); }70:T427,The limited frame constraint doesn't just affect individual processes—it has profound system-wide implications that shape operating system design. **1. Admission Control** The OS may need to limit how many processes can run concurrently. If admitting another process would reduce everyone's frame allocation below useful levels, it's better to make the new process wait. This is fundamentally different from CPU scheduling, where adding another process simply means everyone gets smaller time slices. **2. Degree of Multiprogramming** The **degree of multiprogramming** is the number of processes in memory simultaneously. Too low, and the CPU sits idle during I/O waits. Too high, and processes thrash. The optimal degree depends on available frames and process characteristics. **3. Memory Pressure Response** When frames are scarce, the system must take action: - Reclaim pages from file cache - Invoke the page replacement algorithm more aggressively - Consider swapping entire processes out - In extreme cases, invoke the OOM (Out Of Memory) killer71:T4be,Understanding the history of memory scarcity provides valuable context for modern systems. **The early days (1960s-1970s):** - Total RAM measured in kilobytes to low megabytes - A 256 KB system was considered well-equipped - Virtual memory was revolutionary because physical memory was so scarce - Frame allocation was manual—operators decided which jobs ran together **The PC era (1980s-1990s):** - Early PCs had 64 KB to 640 KB of usable RAM - DOS applications carefully managed memory overlays - Windows 3.x introduced virtual memory on PCs - The "640K ought to be enough" myth reflects how scarce memory seemed **The modern era (2000s-present):** - Systems commonly have 8-64 GB RAM - But applications have grown faster than RAM: - Chrome with tabs: gigabytes - Modern IDEs: gigabytes - Databases: as much as available - Machine learning: hundreds of gigabytes for model training **The constancy of scarcity:** Despite a millionfold increase in RAM capacity, memory scarcity persists. Developers expand their applications to fill available memory. Parkinson's Law applies to memory: "Work expands to fill the time available for its completion"—and software expands to fill available memory.62:{"json":{"id":"seed_7eb4cabb2654d6a0caedcc8919ad04b8","slug":"frame-allocation-problem","category":"Operating Systems","topic":"Frame Allocation & Thrashing","title":"Frame Allocation Problem","description":"Master the fundamental challenge of distributing limited physical memory frames among competing processes. Explore minimum frame requirements, allocation strategies, and fairness considerations that determine system performance and stability.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_67959125833b06ab2d9700c84c0c812b","title":"Limited Frames","order":0,"content":[{"id":"opening-hook","title":"The Fundamental Constraint","content":[{"data":{"content":"At the heart of every memory management challenge lies a simple, immutable truth: **physical memory is finite, but the demand for it is virtually unlimited.** Every process believes it deserves as much memory as it needs, yet the system has only so many physical frames to distribute.\n\nThis scarcity creates the **frame allocation problem**—one of the most consequential decisions an operating system must make. Give a process too few frames, and it thrashes, spending more time waiting for pages than doing useful work. Give it too many, and other processes starve, or the system cannot support as many concurrent processes as it should.\n\nThe elegance—and difficulty—of frame allocation lies in finding the balance point where every process has enough memory to run efficiently, while the system maximizes overall throughput and fairness."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Master","content":"By the end of this page, you will deeply understand why physical memory scarcity is the driving force behind frame allocation policies, how to calculate available frames, and why this constraint shapes nearly every design decision in virtual memory systems.","variant":"info"},"type":"callout"}]},{"id":"physical-memory-scarcity","title":"The Nature of Physical Memory Scarcity","content":[{"data":{"content":"$6a"},"type":"text"},{"data":{"rows":[["Kernel + Drivers","1-2 GB","256K-512K","Non-pageable, always resident"],["System Caches","2-4 GB","512K-1M","Page cache, buffer cache, slab"],["Desktop Environment","1-2 GB","256K-512K","Window manager, compositor"],["Browser (10 tabs)","2-4 GB","512K-1M","Modern browsers are memory-hungry"],["IDE / Editor","1-2 GB","256K-512K","Indexing, language servers"],["Background Services","1-2 GB","256K-512K","Databases, daemons, agents"],["**Total Pressure**","**8-16 GB**","**2M-4M**","**Often exceeds physical RAM**"]],"caption":"Typical Memory Consumers in a 16 GB System","headers":["Consumer","Typical Usage","Frames (4 KB pages)","Notes"]},"type":"table"},{"data":{"content":"**The overcommitment reality:**\n\nModern systems routinely **overcommit** memory—the total virtual memory allocated to all processes exceeds physical RAM. This is intentional and beneficial:\n\n1. **Sparse usage:** Most processes allocate more memory than they actively use at any instant\n2. **Demand paging:** Pages are only loaded when accessed, not when allocated\n3. **Sharing:** Code pages, libraries, and files can be shared across processes\n4. **Copy-on-write:** Forked processes initially share memory with parents\n\nHowever, overcommitment means that at any moment, the system must decide which pages reside in physical frames and which remain on disk. This decision is frame allocation."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Core Tension","content":"Virtual memory allows processes to believe they have abundant memory. Physical memory enforces the reality of scarcity. Frame allocation is the bridge between illusion and reality—it determines which parts of the illusion are backed by fast RAM and which are relegated to slow disk storage.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"calculating-available-frames","title":"Calculating Available Frames","content":[{"data":{"content":"$6b"},"type":"text"},{"data":{"fileName":"frame_calculation.c","languages":[{"code":"$6c","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Dynamic availability:**\n\nThe number of frames available for allocation isn't static. It changes based on:\n\n- **Page cache pressure:** The OS can reclaim pages used for caching files when memory is needed\n- **Kernel memory usage:** Some kernel allocations can grow or shrink (e.g., network buffers during heavy traffic)\n- **Swapping decisions:** As processes are swapped out, their frames become available for others\n- **Hardware hotplug:** On some systems, memory can be added or removed dynamically\n\nThe operating system maintains several lists to track frame status:\n\n1. **Free list:** Frames immediately available for allocation\n2. **Active list:** Frames in use, recently accessed\n3. **Inactive list:** Frames in use, not recently accessed (candidates for reclamation)\n4. **Dirty list:** Frames with modified data that must be written before reclamation"},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"multiplexing-challenge","title":"The Multiplexing Challenge","content":[{"data":{"content":"$6d"},"type":"text"},{"data":{"left":[{"data":{"items":["**Granularity:** Milliseconds","**Switch cost:** ~1-10 microseconds","**Minimum quantum:** 1 ms feasible","**Sharing model:** Time-sliced","**Overhead:** Very low","**Starvation:** Easily prevented"],"title":{"icon":"Zap","text":"CPU Time Multiplexing","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Granularity:** Pages (4 KB+)","**Switch cost:** ~5-15 milliseconds (disk I/O)","**Minimum allocation:** 10s-100s of frames","**Sharing model:** Space-divided","**Overhead:** Extremely high if wrong","**Starvation:** Can cause thrashing"],"title":{"icon":"AlertCircle","text":"Memory Frame Multiplexing","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**The 10,000x difference:**\n\nConsider the cost difference between switching contexts and switching pages:\n\n- **Context switch:** Save registers, switch page tables, restore registers. ~1-10 μs\n- **Page fault with disk I/O:** Trap to kernel, locate page on disk, initiate I/O, wait for disk, load page, update page table, restart instruction. ~5-15 ms\n\nThis is a **1,000-15,000x difference**. A process experiencing page faults for even 1% of its memory accesses can see performance degradation of 100x or more. This is why frame allocation decisions have such dramatic impact on system performance."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Cliff Effect","content":"Unlike CPU scheduling where giving a process less time means proportionally slower execution, memory allocation has a cliff effect. Give a process 90% of needed frames, and it might run at 80% efficiency. Give it 60%, and it might run at 5% efficiency due to constant page faults. This non-linear degradation makes frame allocation particularly challenging.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"scarcity-scenarios","title":"Frame Scarcity Scenarios","content":[{"data":{"content":"$6e"},"type":"text"},{"data":{"fileName":"scarcity_simulation.c","languages":[{"code":"$6f","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Key Insight","content":"The simulation reveals why allocation strategy matters enormously. Equal allocation might seem fair but can leave large processes thrashing while small processes have excess frames. Proportional allocation better matches actual needs but may starve small but critical processes. There is no universally optimal strategy—each involves tradeoffs.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"system-implications","title":"System-Wide Implications","content":[{"data":{"content":"$70"},"type":"text"},{"data":{"items":["**Low pressure:** Free frames available, file cache can grow, allocation is instant","**Medium pressure:** Free frames depleted, reclaiming from file cache, slight slowdown in allocations","**High pressure:** Actively paging out user memory, page replacement algorithm running continuously","**Critical pressure:** Swapping processes to disk, significant I/O overhead, system becoming sluggish","**OOM condition:** No memory available even after aggressive reclamation, must kill processes to survive"],"title":{"icon":"Target","text":"Memory Pressure Levels","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**4. Performance Cliffs**\n\nAs memory pressure increases, performance doesn't degrade linearly. Systems exhibit **performance cliffs** where small increases in memory pressure cause dramatic performance drops:"},"type":"text"},{"data":{"rows":[["0-60%","Full speed, frames abundant"],["60-80%","Minor slowdowns, file cache shrinking"],["80-90%","Noticeable delays, page reclamation active"],["90-95%","Significant slowdown, swap activity"],["95-100%","Thrashing zone, system may be unusable"]],"headers":["Memory Utilization","Typical Performance"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Thrashing Disaster","content":"When every process is given too few frames, they all fault constantly. The disk becomes saturated with paging I/O. CPU utilization drops to near zero as all processes wait for pages. The system appears frozen. This is thrashing—and it's entirely preventable with proper frame allocation policies. We'll explore thrashing in depth in later modules.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"historical-perspective","title":"Historical Perspective","content":[{"data":{"content":"$71"},"type":"text"},{"data":{"rows":[["1970s Mainframe","2 MB","Batch job: 256 KB","8:1 oversubscription"],["1990s Desktop","16 MB","Office suite: 4 MB","4:1 possible"],["2000s Desktop","512 MB","Browser + Office: 256 MB","2:1 comfortable"],["2010s Laptop","8 GB","Modern workflow: 6 GB","1.3:1 tight"],["2020s Workstation","32 GB","Dev environment: 20+ GB","1.5:1 still constrained"]],"caption":"Evolution of Memory Scarcity","headers":["Era","Typical RAM","Typical Application","Scarcity Ratio"]},"type":"table"},{"data":{"icon":"Info","title":"The More Things Change...","content":"Despite enormous increases in physical RAM, the fundamental problem remains: aggregate demand exceeds supply. The frame allocation problem is as relevant today as it was in the earliest virtual memory systems. The scale has changed; the challenge has not.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"design-implications","title":"Implications for System Design","content":[{"data":{"content":"The reality of limited frames shapes operating system design in profound ways.\n\n**Lazy allocation everywhere:**\n\nBecause frames are precious, OSes delay allocation as long as possible:\n- **Demand paging:** Don't load pages until accessed\n- **Copy-on-write:** Don't copy pages until modified\n- **Zero-fill-on-demand:** Don't allocate writable pages until written\n- **Overcommit:** Allow allocations that exceed physical memory\n\n**Reclamation mechanisms:**\n\nBecause demand exceeds supply, OSes must constantly reclaim frames:\n- Page replacement algorithms (LRU, Clock, etc.)\n- Page cache shrinkage under pressure\n- Swap space for backing evicted pages\n- OOM killer as last resort\n\n**Admission and load control:**\n\nTo prevent thrashing, OSes may limit concurrency:\n- Working set tracking to estimate process needs\n- Page fault frequency monitoring\n- Automatic process suspension/swapping\n- Memory cgroups and limits in containers"},"type":"text"},{"data":{"type":"ordered","items":["**Assume overcommitment:** Design for the case where total virtual memory exceeds physical memory","**Delay everything possible:** Allocate frames only when absolutely necessary","**Have a reclamation strategy:** Know how to get frames back when needed","**Monitor and adapt:** Track memory pressure and adjust behavior accordingly","**Fail gracefully:** When memory is exhausted, fail predictably rather than randomly","**Prioritize wisely:** Not all pages are equally important—know which to keep"],"title":{"icon":"CheckCircle","text":"Design Principles Derived from Frame Scarcity","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"For System Designers","content":"Every feature that consumes memory should consider frame allocation implications. Caches should be tunable and shrinkable. Allocations should be lazy. Memory usage should be monitorable. The assumption of abundant memory leads to systems that collapse under load—assume scarcity and design accordingly.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: The Scarcity Imperative","content":[{"data":{"content":"We've established the fundamental constraint that drives all frame allocation decisions: physical memory is finite while virtual memory and process demands are essentially unlimited.\n\nThis page has built the conceptual foundation for understanding frame allocation. The key insights are:"},"type":"text"},{"data":{"type":"ordered","items":["**Physical memory is fixed** — Unlike virtual memory, RAM capacity is a hard constraint","**Overcommitment is normal** — Total virtual allocations routinely exceed physical memory","**Frame switching is expensive** — Unlike CPU time, reallocating frames requires slow disk I/O","**Non-linear degradation** — Insufficient frames cause disproportionate performance loss","**Scarcity is eternal** — Despite RAM growth, demand grows faster; the problem persists","**Design assumes scarcity** — Every OS mechanism reflects the reality of limited frames"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that we understand why frame scarcity exists and its implications, we'll examine **process requirements**—how to determine how many frames each process actually needs. This leads directly to allocation strategies that balance efficiency, fairness, and system stability."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the fundamental constraint of limited frames and why it makes frame allocation one of the most critical decisions in operating system design. Next, we'll explore how to determine what each process actually requires from this limited pool.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_ebf7da9d1056654d295a839c580eaca0","title":"Process Requirements","order":1,"content":null,"isLocked":true},{"id":"seed_88d0e9ee901ce2fdd3ce9b61cfad360e","title":"Minimum Frames","order":2,"content":null,"isLocked":true},{"id":"seed_69b1f32805b3236a20f88f455aa72909","title":"Allocation Strategies","order":3,"content":null,"isLocked":true},{"id":"seed_11601f2ecce60146969fa4dd01873a8a","title":"Fairness Considerations","order":4,"content":null,"isLocked":true}]}}