In virtual memory systems, which statement best explains a primary cause of thrashing and its relationship to paging policy?

Introduction / Context:
Thrashing occurs when a system spends disproportionate time servicing page faults and moving pages rather than executing useful work. It typically emerges when the working set exceeds available frames or when replacement policies interact badly with workload locality. Understanding the cause guides tuning and policy selection.

Given Data / Assumptions:

• Demand-paged virtual memory is in use.
• There is finite physical memory and active multiprogramming.
• Replacement and admission control policies affect fault rates.

Concept / Approach:
Poor paging algorithms (for example, those that ignore locality or oscillate between hot sets) can trigger or exacerbate thrashing. If the policy continually evicts pages that will be imminently referenced, the fault rate skyrockets. Proper policies (for example, approximations to LRU, working-set models, or page coloring with admission control) maintain locality and reduce faults.

Step-by-Step Solution:

Verification / Alternative check:
Tracing memory references shows working-set churn; after policy correction or increasing frames, the system transitions from fault-dominated to compute-dominated behavior, confirming the root cause.

Why Other Options Are Wrong:

• Unavoidable consequence: False; many systems run without thrashing under proper policies and adequate memory.
• Avoided by swapping: Swapping entire processes is not a universal solution and may worsen contention.
• Always on large computers: Size is irrelevant; policy and workload matter.
• None of the above: Incorrect; poor paging algorithms can cause thrashing.

Common Pitfalls:
Blaming hardware alone, or adding load without adjusting degree of multiprogramming, leading to working-set overcommitment and cascading faults.

Final Answer:
Can be caused by poor paging algorithms