CLOCK-Pro sits in a specific historical spot: ARC solved the recency-vs-frequency tension elegantly, but IBM patented it, which spooked open-source projects. CLOCK-Pro (Jiang, Chen, Zhang, 2005) delivers ARC-class hit rates using CLOCK's cheap circular-buffer mechanics — no patents, no per-access locking, and it's what NetBSD, Apache Traffic Server, and PostgreSQL-adjacent research prototypes reached for.

The core insight: don't classify pages by recency (LRU) or frequency (LFU). Classify them by reuse distance — how many distinct pages you touched between two accesses of the same page. Short reuse distance = "hot." Long reuse distance = "cold." A page scanned once has infinite reuse distance and should die fast.

CLOCK-Pro maintains one circular list containing three page types:

• Hot pages (H) — resident, short reuse distance, protected.
• Cold pages (C) — resident, either newly admitted or demoted from hot.
• Test pages (T) — non-resident metadata only, tracking recently evicted colds to detect if they deserve promotion.

Three hands sweep the clock: hand_hot demotes unreferenced hots to cold, hand_cold evicts unreferenced colds (leaving a test entry), and hand_test ages out stale test entries. If a cold page gets re-accessed while its test entry still exists, it graduates to hot — proof it has short reuse distance.

Concrete example: Your database buffer pool holds 10,000 pages. A nightly analytics job scans a 50,000-page table. Under LRU, that scan evicts your entire working set — tomorrow morning's OLTP traffic hits cold cache. Under CLOCK-Pro, the scan pages enter as cold, never get re-referenced before hand_cold sweeps them, and get evicted without ever touching your hot set. Your OLTP pages sit protected in the hot region. Measured hit rates on mixed OLTP+scan workloads typically beat LRU by 15-40%.

Rule of thumb for sizing: Let hot pages consume roughly 1% of cache initially and let CLOCK-Pro adapt. The algorithm auto-tunes the hot/cold split based on whether test-page hits are increasing (grow hot region) or hot demotions dominate (shrink it). Target ratio of test entries to resident pages is 1:1 — enough history to detect promotions without exploding metadata.

When to skip it: If your workload is uniformly random (no reuse structure), CLOCK-Pro's bookkeeping is pure overhead — use plain CLOCK. If you have strict recency semantics (session caches, TTL-dominant), LRU or SLRU is simpler. CLOCK-Pro shines specifically when scan-resistance matters and you can't afford ARC's licensing or per-access list surgery.