frame allocation
Imagine sharing a fixed number of chairs among several work teams in one room. Give a team too few chairs and its members keep standing up and sitting down, wasting time; give one team almost all of them and the others grind to a halt. Someone has to decide how many chairs each team gets, fairly and sensibly. Frame allocation is the OS making this decision for physical memory: how many frames (the fixed-size slots that hold pages) each process is allowed to keep at once.
Concretely, physical RAM holds a fixed number of frames, and they must be divided among all the processes competing for memory. A frame-allocation policy decides each process's share. The simplest is equal allocation: split frames evenly. More sensible is proportional allocation: give each process a number of frames in proportion to its size or its working-set demand, so a big program gets more than a tiny one. Allocation interacts closely with page replacement: under local replacement a process can only steal frames from its own set when it faults, so its allocation is effectively fixed; under global replacement a faulting process can take a frame from any process, so allocations float dynamically. There is usually a minimum number of frames a process must have — enough to hold all the pages a single instruction might touch at once, or it could never make progress.
Why it matters: frame allocation is the dial that sets each process's page-fault rate, and it is the direct lever on thrashing. If a process is given fewer frames than its working set needs, it faults constantly no matter how clever the replacement policy; give it enough and faults become rare. The working-set model turns this into a concrete target: allocate each process about as many frames as its working set, and admit new processes only while their working sets still fit. The honest tension: frames are scarce and shared, so generosity to one process is scarcity for another — frame allocation is fundamentally about balancing competing demands so that the whole system, not just one program, runs well.
A system has 100 free frames and 4 processes. Equal allocation gives each 25. Proportional allocation, by size, might give a 200-page process about 67 frames and a 100-page process about 33 — closer to what each actually needs.
Too few frames for a process's working set means relentless faulting.
Every process needs a minimum number of frames set by the architecture — enough to hold all the pages one instruction can reference at once (including the operands of, say, an indirect memory-to-memory move); below that minimum it cannot even complete a single instruction, so the fault would never resolve.