global vs local replacement

When a process faults and a victim must be chosen, there is a prior question: may it steal a frame from any process, or only from itself? Imagine an office where everyone shares one supply cupboard. Global replacement is the rule that a person short on pens may take a pen from anyone's drawer; local replacement is the rule that each person has a fixed personal stash and may only rearrange their own. That choice — whose frames are eligible to be the victim — is global versus local replacement.

Under global replacement, when process P faults the OS may select a victim from the entire pool of frames, including frames currently belonging to other processes. The set of frames a process holds can therefore grow or shrink over time depending on the behaviour of all processes. Under local replacement, each process is given a fixed allotment of frames and may only replace among its own pages; if it needs a page and its frames are full, it must evict one of its own, and it can never grab another process's frame. Equal and proportional frame-allocation policies decide how many frames each process gets in the first place; global versus local decides whether those boundaries can be crossed during replacement.

Why it matters: the two have a real trade-off. Global replacement usually gives better overall throughput because frames flow to whoever needs them most, but it means a process's page-fault rate depends on the behaviour of others — your performance is no longer in your own hands, and one greedy process can starve the rest and trigger thrashing. Local replacement gives each process a stable, predictable performance because its frame count is fixed, but it can leave frames idle in one process while another is desperate. Many systems lean global for efficiency and then bolt on controls (like working-set or page-fault-frequency schemes) to stop the thrashing global replacement can otherwise cause.