Dirty memory page 2026-10-14
A resident memory page with modifications that must be preserved in its backing storage before its page frame can be reused. In the simple model here, a write sets its dirty flag, and successful page writeback clears it. A clean memory page with a recoverable backing copy can be discarded without an outgoing data write.[ref]
LRU stack property 2026-10-14
For exact LRU replacement, let be the resident set after the first accesses of a fixed page-reference trace with capacity . With empty starts, identical access order, freely placeable memory pages, and all resident memory pages eligible for eviction,
Here means subset. At every time, form one capacity-independent ordered list of distinct memory pages, most recently accessed first. An access moves its memory page to the front, preserving the order of the others. Exact LRU replacement with page frames retains the first entries, or all entries if fewer than have appeared. The first entries are contained in the first , proving the property. This recency list is not the push/pop interface of a LIFO stack.[ref]
Apply inclusion immediately before an access: a hit with page frames must also hit with . Thus cumulative misses with cannot exceed those with , at any prefix of the same page-reference trace. On the displayed sequence, the counts decrease from ten to eight when capacity increases from three to four. Arbitrary initial contents, different access orders, protected victims, or clean-victim preference fall outside the proof. Nor does it prove monotonic page writeback costs, or apply automatically to CLOCK page replacement just because that policy approximates LRU replacement.
// Destination: computer-science.bigb
There are two distinct questions: whether another operating-system process can observe shared contents, and whether those contents survive a crash. In the timeline, persistent storage deliberately remains while the shared page cache contains . No background page writeback occurs in this toy interval. Real page writeback may persist some contents earlier; shared visibility alone cannot tell the reader which contents are durable.
For the covered shared range, msync(base, length, MS_SYNC) requests page writeback and waits for completion; check its return value. MS_ASYNC is not a durable completion acknowledgment, and on modern Linux kernel versions it is a no-op because dirty contents are already tracked. The address must be aligned, so synchronizing our changed second page uses base + 4096, length 4096, rather than base + 4133. Unmapping alone is not a guarantee of completed writeback.[ref]
For persistence of the file and associated file metadata, fsync on an open file descriptor is a broader interface; a new directory entry needs separate synchronization of its file-system directory. Retain a suitable file descriptor if the persistence protocol needs it after mapping. Successful storage completion still relies on the file system and device honoring their persistence contracts.[ref]
Neither fsync nor msync supplies mutual exclusion, an atomic storage write for several memory pages, or an application-wide file-system transaction. Stop or coordinate writers before deciding which update a completion acknowledges. A crash during page writeback can leave a mixture of old and new contents unless a separate recovery protocol provides file-system crash consistency. The last timeline row assumes successful synchronous completion, honored storage flush semantics and no subsequent writer; it illustrates a persistence boundary, not a promise about arbitrary hardware failures.
Optimal page replacement 2026-10-14
On a miss with all page frames occupied, evict the resident memory page whose next access is farthest in the remaining page-reference trace. Treat no further access as farther than any finite next-use index; in the diagram, ties choose the lowest-numbered page frame. This is an offline, clairvoyant benchmark: a general operating system cannot know its future memory references. It minimizes miss count in the stated fixed-capacity demand paging model, rather than predicting the future from temporal locality.[ref]
In the page-reference trace, seven misses with three page frames is therefore a lower bound for any policy using the same assumptions; with four page frames the corresponding minimum is six. The benchmark is useful for judging how much improvement is possible on a recorded workload. Its objective counts each miss equally. Different page writeback costs or unequal loading costs require a different objective; minimum misses alone does not prove minimum elapsed time.
Page replacement 2026-10-14
Choosing a resident memory page to evict when another memory page needs an occupied page frame. An unused page frame needs no eviction. A dirty memory page requires preservation before reuse, accounted for separately as page writeback. A page replacement policy balances likely future reuse against the overhead of tracking past memory references.
The opportunity comes from temporal locality: retaining a recently accessed memory page can spare a later nonresident page fault. Spatial locality helps consecutive accesses reuse the same memory page until they cross its boundary. A working set describes recent demand, while the resident set describes what is actually present. A small active footprint can fit in the available page frames even when the whole address space cannot. These are useful workload tendencies, not guarantees about future memory references.[ref]
The page-reference trace below uses the counterexample discussed in Operating Systems: Three Easy Pieces by Remzi H. Arpaci-Dusseau and others (chapter 22, p. 5) and makes the decisions explicit. FIFO page replacement ranks arrival time, LRU replacement ranks last access, CLOCK page replacement samples recent use, and optimal page replacement knows the remaining sequence in advance. Count misses first; page-replacement cost accounting separately counts page writeback and explains why fewer misses need not mean less total service time.
// Destination: computer-science.bigb
Let be the number of accesses, the miss count and the number of dirty-victim page writebacks. Assume every requested memory page has a backing copy, every miss reads it, writes modify only part of its contents, transfers succeed and occur serially, and there is no background or final flushing. With common access cost , additional load cost per miss, and additional outgoing write cost per dirty victim, an illustrative total service time is
Bookkeeping and other operating system costs are omitted. The two transfer directions are separate: a miss can require a read with no write, or both a victim write and a requested-page read. A retained dirty memory page contributes no outgoing write to this finite-page-reference trace count until evicted. Future flushing would need its own accounting boundary.
For three-page frame FIFO page replacement on the displayed page-reference trace, all reads give . Change only access 1 to a partial write of memory page 1. Its initial miss still loads the old contents, the write marks it dirty, and eviction at access 4 adds exactly one page writeback. Later loads of memory page 1 are clean because the remaining accesses read. The result is : identical residency and nine misses, but one extra outgoing write. With illustrative nanoseconds, millisecond and milliseconds, total service time changes from to milliseconds. These are model costs, not hardware measurements.
Preferring a clean victim can save an immediate page writeback, but evicting a soon-needed clean memory page can add later misses. This tradeoff is why a miss-minimizing optimal page replacement benchmark and a minimum-cost policy are different questions. Real page faults can also initialize a new memory page or perform copy-on-write without reading backing storage; those cases require different load costs.
// Destination: computer-science.bigb
Page writeback 2026-10-14
Preserving the modified contents of a dirty memory page in its backing storage. The reference model waits for successful page writeback before reusing the victim's page frame; failure cannot authorize losing its modifications. A reference bit records recent access, while the dirty flag records a write obligation: reading can set the first without setting the second. Buffer cache writeback concerns the analogous obligation for a buffered device block.
Private file mapping 2026-10-14
With MAP_PRIVATE, copy-on-write initially reuses backing page cache contents. In our model, a private store raises a protection page fault, copies the affected memory page to a private page frame, installs a writable page table entry and retries. The other memory page can remain shared. This page fault needs no storage read.
In B's private file mapping, storing copies relative page 1, including its neighbor . Next, A stores through its shared file mapping. After coordination outside the mapped data, B's shared reads give , while its detached private page gives . The untouched first memory page remains backed by the file; this is not a frozen snapshot of the whole file. Neither page writeback of shared contents nor msync publishes B's private 99. To save those private contents, the application needs a separate explicit file update.
Figure 1.
Toy shared file mapping and copy-on-write timeline: visible shared changes precede the chosen durable completion; private changes remain separate
. Details.
Shared file mapping 2026-10-14
With MAP_SHARED, updates are visible to other operating-system processes mapping the same region and are carried through to the backing file. With MAP_PRIVATE, updates instead stay private, and later backing file changes have unspecified visibility in that mapping.[ref]
In the toy model, both shared file mappings initially read backing bytes at file offsets 8229 and 8230. Both memory pages have been accessed, so their translations are installed. A shared store changes the common page cache contents and creates a dirty memory page eligible for page writeback. That change can be observed before it reaches persistent storage. Cooperating readers need synchronization to know when an update is ready; MAP_SHARED alone supplies no mutual exclusion or indivisible multi-field update.