Linux Page Cache Interview Questions: Cached Memory, Writeback, and I/O Pressure

A Linux host shows little “free” memory, a large Cached value, and slow writes. Is the page cache causing an out-of-memory failure, or is it helping the system? A useful interview answer resists both shortcuts. It distinguishes clean cache that may be reclaimable, dirty pages waiting for writeback, and actual task stalls before recommending a change.

The kernel behavior and metric names below come from Linux kernel page-cache documentation, proc_meminfo(5), and the kernel's VM sysctl guide. The numbers and diagnosis exercises are original examples, not candidate reports or claims about a company's interview. For wider resource debugging, read the Linux cgroups guide.

Question 1: What is the page cache actually caching?

The page cache holds file-backed data in memory so that repeated reads can avoid a storage fetch, and it participates in buffered writes. When an application reads a file, data may already be resident. When it writes through buffered I/O, modified pages can remain in memory as dirty pages before writeback. That makes the page cache a performance feature and a memory consumer at the same time.

Do not describe cache as a single disposable pile. Some cached pages are clean and can often be reclaimed more readily; dirty pages generally need writeback before their memory can be reused without losing changes. Active use, filesystem behavior, memory cgroups, and competing workloads affect reclaim. The Cached field in /proc/meminfo is an aggregate, not a promise that every byte can be given to your process instantly or cheaply.

The related MemAvailable field estimates memory available for starting applications without swapping, taking account of free memory, reclaimable page cache, and other factors. It is a better first read than treating MemFree as capacity, but it remains an estimate. A small MemFree value by itself is normal on a host that uses otherwise idle RAM as cache. A confident diagnosis needs time trends and pressure signals, not one snapshot.

Question 2: Which counters distinguish cache from writeback?

Read /proc/meminfo over the incident interval. Cached approximates memory used for file cache; Dirty represents memory waiting to be written back; Writeback is memory currently being written out. Interpret changes alongside MemAvailable, swap activity, application resident memory, and I/O pressure. Do not add every field as if they were independent buckets: kernel counters have definitions and overlaps, and their accounting can vary by kernel and configuration.

Suppose an ingest worker writes many files and Dirty rises rapidly. A rising dirty count says data is accumulating faster than it is being cleaned over that sample window. It does not prove a disk is failing. The workload may be bursty, writeback may be intentionally deferred, or a storage device may be saturated. Check the device's throughput, latency, queueing, filesystem errors, and the writer's own latency before assigning cause.

The VM sysctl guide describes dirty-page controls such as dirty_background_bytes and dirty_bytes (or corresponding ratios). They influence when background writeback starts and when writers participate in writeback. Those settings describe control behavior; they are not a magic target for “how much RAM is safe to cache.” Changing them without measuring the write rate and storage service rate can shift stalls or increase risk elsewhere.

An incident matrix: clean cache, dirty pages, or pressure?

This table is an original practice aid. It maps observations to hypotheses and the next discriminating check. None of its rows establishes a root cause alone.

Observation over the same window	Plausible reading	What to check next
MemFree low, Cached high, MemAvailable steady, low stalls	RAM is being used as cache without clear pressure	Read latency, workload baseline, reclaim trend
Dirty grows while Writeback and device latency rise	Writes may outrun cleaning capacity	Filesystem/device queue and per-workload write rate
MemAvailable falls and memory PSI rises	Tasks may be stalling on memory pressure or reclaim	Swap, faults, cgroup limits, per-process and cache composition
I/O PSI rises, Dirty oscillates, writer p99 grows	Writeback or other I/O contention may be affecting requests	Device utilization, queue depth, application path
Cached falls after a competing allocation and no SLA regresses	Cache was reclaimed for the new demand	Recheck faults and latency before calling it harmless

Notice the difference between amount and cost. Dirty is an amount of not-yet-written memory; I/O pressure stall information describes time tasks spend unable to progress because of I/O pressure. A machine can have a large cache with little user-visible cost, or a modest dirty backlog and severe tail latency if storage is slow. The kernel's PSI documentation explains pressure as a time-based signal, which helps interpret utilization graphs that appear unremarkable.

Question 3: When is a write durable?

A successful buffered write() generally tells the application that data was accepted into the kernel's write path; it does not by itself establish that the bytes and needed metadata are durable on stable storage. The fsync(2) manual documents a synchronization boundary for file data and associated metadata, with important details for directory entries. The exact durability guarantee also depends on filesystem and hardware behavior.

In an interview, ask whether the product requires durability after every record, after a batch, or only eventual persistence. A database or log can use an explicit fsync policy; a temporary cache file may tolerate loss. This is a product requirement, not a metric setting. If the interviewer says “the write returned successfully, but the machine crashed,” it is incorrect to conclude the data must survive merely because the application observed success.

Do not equate Dirty falling with a specific transaction being durable. Background writeback and an explicit sync operation are different events. Nor does a single fsync on a newly created file necessarily cover every directory-entry durability requirement; the fsync(2) documentation calls out the parent directory. State the scope of your guarantee and the filesystem assumptions before making a claim about recovery.

Question 4: Does dropping caches fix memory pressure?

Usually the better answer is to diagnose the pressure source first. The kernel exposes drop_caches for reclaiming selected clean caches, but its documentation warns against using it as a routine performance-control mechanism. Removing useful cache can make subsequent reads miss and increase I/O. It does not repair a process leak, a too-small cgroup limit, or a storage path unable to sustain writeback. Dirty data requires its own safe writeback path; dropping clean cache is not a substitute for durability.

If a test intentionally compares warm-cache and cold-cache behavior, describe it as a controlled experiment with a defined workload and rollback. In production, use the observed memory, I/O, and application behavior to decide. The key question is whether cache is being reclaimed in response to demand and what that reclaim costs. If MemAvailable stays healthy and PSI is low, a high Cached line alone is not a reason to disrupt the system.

Also avoid a simplistic “RSS versus cache” equation. A process may map files, and memory accounting across process, cgroup, and host views is not interchangeable. A container can face its own memory limit while the host has available memory; the host-level /proc/meminfo may hide that local boundary. If the scenario names a container, examine the relevant cgroup's memory.current, memory.stat, and pressure files as well as host totals. Our Linux cgroups guide covers that boundary separately.

Question 5: How do you test the writeback hypothesis?

Build a shared timeline with request p99, write rate, dirty and writeback bytes, I/O PSI, device latency, and filesystem errors. Sample before, during, and after the slowdown; a lifetime counter cannot establish what changed during this incident. Split the workload by writer if possible. A large batch import may explain the same host-wide pressure graph that a small API service experiences as latency.

Then make one controlled change that can falsify the hypothesis. Throttle or pause the identified batch writer, or route a small test workload to a known storage path, and observe both the writer and affected readers. If I/O PSI and API p99 recover together while write backlog falls, writeback contention becomes more credible. If p99 stays high and storage latency is normal, inspect locks, CPU, network, and application queues instead.

Be careful with causality. A request surge can simultaneously create more dirty pages, more CPU work, and longer queues. Correlation between Dirty and latency is a clue, not proof. A strong answer tells the interviewer what result would reject the first diagnosis. It also states the operational tradeoff: reducing buffered writes or raising dirty limits may move the symptom without improving the storage device's sustained capacity.

If the test pauses a writer and p99 improves, compare the result with a control period at similar request volume. Otherwise a falling request rate may explain both the lower dirty count and the better latency. Record the change time, affected host, and recovery lag; writeback can continue after an application stops producing new dirty pages.

A concise interview answer

“I would not call low MemFree a leak. The page cache is useful file-backed memory, but clean and dirty pages have different reclaim costs. I would compare MemAvailable, Cached, Dirty, and Writeback across the incident window and add memory and I/O PSI to see whether tasks actually stalled. If a writer slows, I would correlate its rate with device latency and writeback. A successful buffered write does not guarantee crash durability; I would check the application's fsync policy. I would not drop caches or tune dirty limits until a controlled test supports the cause.”

The answer is specific enough to be tested. It distinguishes memory capacity from write-path pressure and durability. It also avoids using a single host graph to diagnose a container. If the interviewer changes the scenario from buffered file writes to direct I/O, ask which operations bypass or interact differently with page cache before applying the same explanation.

Practice question	Connection to this scenario
Investigate High Memory Usage	Separate cache growth from application memory growth.
Diagnose Storage I/O Performance and Identify the Workload	Identify the writer and storage bottleneck.
Diagnose I/O, Memory, and CPU Constraints	Compare pressure mechanisms.
Linux Host and Filesystem Fundamentals	Explain filesystem and host metric boundaries.
Troubleshoot a production server outage	Turn correlated graphs into a falsifiable incident hypothesis.

Try the Linux cgroups practice guide after this one. In a mock interview, make the interviewer choose between a host and container problem; your diagnostic files and conclusions should change accordingly.

Sources and further reading

• Linux kernel: Page cache — file-backed cache concepts.
• Linux manual: proc_meminfo(5) — Cached, Dirty, Writeback, and MemAvailable definitions.
• Linux kernel: VM sysctl — dirty-page and cache-control interfaces.
• Linux kernel: Pressure stall information — task-stall interpretation.
• Linux manual: fsync(2) — explicit synchronization and directory-entry boundary.