[PATCH v2] vm_swappiness=0 should still try to avoid swapping anon memory

[PATCH v2] vm_swappiness=0 should still try to avoid swapping anon memory

[Nico Pache]

Since 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.

This does not completely disable swapping, but rather tames the
refaulting aspect of the code that allows for the deactivating of anon
memory.

A similar solution may be possible in the get_scan_count() part of the
code, which determines the reclaim pressure for each LRU; however I
believe that kind of solution may be too aggressive, and not allow other
parts of the code (like direct reclaim) from targeting the active_anon
list. This way we stop the problem at the heart of what is causing the
issue, with the least amount of interference in other code paths.

Furthermore, shrink_lruvec can modify the reclaim pressure of each LRU,
which may make the get_scan_count solution even trickier.

Changelog:
 -v2: made this mem_cgroup specific so now it will work with v1, v2, and
   no cgroups. I've also touched up my commit log.

Signed-off-by: Nico Pache <npache@redhat.com>
---
 mm/vmscan.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4620df62f0ff..89d4e84011b7 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2909,8 +2909,9 @@ static void shrink_node(pg_data_t *pgdat, struct scan_control *sc)
 
 		refaults = lruvec_page_state(target_lruvec,
 				WORKINGSET_ACTIVATE_ANON);
-		if (refaults != target_lruvec->refaults[0] ||
-			inactive_is_low(target_lruvec, LRU_INACTIVE_ANON))
+		if (mem_cgroup_swappiness(sc->target_mem_cgroup) &&
+			(refaults != target_lruvec->refaults[0] ||
+			inactive_is_low(target_lruvec, LRU_INACTIVE_ANON)))
 			sc->may_deactivate |= DEACTIVATE_ANON;
 		else
 			sc->may_deactivate &= ~DEACTIVATE_ANON;
-- 
2.31.1

Re: [PATCH v2] vm_swappiness=0 should still try to avoid swapping anon memory

[Alexey Avramov]

>vm_swappiness=0 should still try to avoid swapping anon memory

Swapping with swappiness=0 depends on vm.watermark_scale_factor.
Decrease vm.watermark_scale_factor to avoid swapping and get OOM,
and increase vm.watermark_scale_factor to get successful swapping 
even with swappiness=0.

Maybe I misunderstood you and you are solving some new problem? 

Re: [PATCH v2] vm_swappiness=0 should still try to avoid swapping anon memory

[Nico Pache]

On 8/7/21 2:14 AM, Alexey Avramov wrote:
>> vm_swappiness=0 should still try to avoid swapping anon memory
> Swapping with swappiness=0 depends on vm.watermark_scale_factor.
> Decrease vm.watermark_scale_factor to avoid swapping and get OOM,
> and increase vm.watermark_scale_factor to get successful swapping 
> even with swappiness=0.
>
> Maybe I misunderstood you and you are solving some new problem? 

The problem is new; however, the two workloads that are now running into this issue are not new (one is as old as RHEL5).

Sorry the issue was attributed to the wrong commit in my V1/V2 posting. This may have caused some confusion. The actual commit to blame is 170b04b7ae49 ("mm/workingset: prepare the workingset detection infrastructure for anon LRU"). I will be posting my V3 soon. It has a much better commit log and fixes a issue that was present in my V2.


This new change allows for challenging the anon memory at a much greater rate. I believe this is ok since it will cause less trashing; however, it may also be the case that the user wants to avoid paying the cost of writing the anon to swap, and would rather throttle the page reads (like has been the case since at least rhel5).


Hopefully my V3 clears up a lot of the questions asked, and my motivations for these changes is more clear.


Cheers!

-- Nico