Since commit 170b04b7ae49 ("mm/workingset: prepare the workingset detectionTypo: "sense" -> "since"
infrastructure for anon LRU") and commit b91ac374346b ("mm: vmscan: enforce
inactive:active ratio at the reclaim root") swappiness can start prematurely
swapping anon memory. This is due to the assumption that refaulting anon should
always allow the shrinker to target anon memory. Add a check for swappiness
being >0 before indiscriminately targeting Anon. Before these commits
when a user had swappiness=0 anon memory would rarely get swapped; this
behavior has remained constant sense RHEL5. This commit keeps that behavior
intact and prevents the new workingset refaulting from challenging the anon
memory when swappiness=0.
Anon can still be swapped to prevent OOM. This does not completely disable
swapping, but rather tames the refaulting aspect of the code that allows for
the deactivating of anon memory.
We have two customer workloads that discovered this issue:
1) A VM claiming 95% of the hosts memory followed by file reads (never dirty)
which begins to challenge the anon. Refaulting the anon working set will then
cause the indiscriminant swapping of the anon.
2) A VM running a in-memory DB is being populated from file reads.
Swappiness is set to 0 or 1 to defer write I/O as much as possible. Once
the customer experienced low memory, swapping anon starts, with
little-to-no PageCache being swapped.