You know MADV_DONTNEED (drop pages, zero-fill on next access) and MADV_FREE (kernel may drop; if it does, next read returns zeros). Both destroy data. Linux 5.4 added two advises that preserve data while still relieving memory pressure: MADV_COLD and MADV_PAGEOUT.

MADV_COLD deactivates the pages — moves them from the active LRU list to the inactive list. The data stays in RAM, but the pages are now the next candidates for reclaim when kswapd runs. It's a hint: "if you need to evict something, evict this first."

MADV_PAGEOUT is more aggressive: it immediately reclaims the pages. File-backed pages are written back (if dirty) and dropped. Anonymous pages are pushed to swap. The virtual mapping stays; the next access takes a major fault and pulls the data back in.

Critically, both preserve the contents. Unlike MADV_DONTNEED, when you touch the page again you get your data back, not zeros. The cost is a page fault (and disk I/O for MADV_PAGEOUT), not data loss.

Real-world example: Android uses MADV_COLD extensively via the Process State framework. When an app moves to the background, ActivityManager calls MADV_COLD on the app's anonymous heap. If memory stays plentiful, the app resumes instantly with everything in RAM. If a foreground app needs memory, the backgrounded pages get evicted first without impacting active workloads. Databases like RocksDB use MADV_PAGEOUT on cold SST file mappings to force writeback of dirty pages before the kernel decides to do it at an inconvenient time.

Rule of thumb: If you know a region won't be touched for >1 second and RAM is contended, use MADV_COLD. If you know it won't be touched for >10 seconds and you'd rather pay the fault cost later on your schedule than let kswapd stall a foreground allocation, use MADV_PAGEOUT. Below ~1 second, the LRU machinery already handles it — you're just adding syscall overhead.

Gotchas:

• MADV_PAGEOUT on anonymous pages requires swap configured. On swap-less systems (many containers), it silently degrades to no-op for anon pages.
• Neither works on locked pages (mlock) or hugepages that haven't been split.
• The syscall itself walks the page tables for the range — advising a 100GB region can take milliseconds. Batch calls or use larger regions rather than per-page advises.