On Fri, Aug 6, 2021 at 4:17 PM Nico Pache <npache@xxxxxxxxxx> wrote: > > 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 vm_swappiness being > >0 before indiscriminately targeting Anon. Did you actually observe this behavior? > > Signed-off-by: Nico Pache <npache@xxxxxxxxxx> > --- > mm/vmscan.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 4620df62f0ff..8b932ff72e37 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2909,8 +2909,8 @@ 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 (vm_swappiness && (refaults != target_lruvec->refaults[0] || > + inactive_is_low(target_lruvec, LRU_INACTIVE_ANON))) If you are really seeing the said behavior then why will this fix it. This is just about deactivating active anon LRU. I would rather look at get_scan_count() to check why swappiness = 0 is still letting the kernel to scan anon LRU. BTW in cgroup v1, the memcg can overwrite their swappiness which will be preferred over system vm_swappiness. Did you set system level swappiness or memcg one? > sc->may_deactivate |= DEACTIVATE_ANON; > else > sc->may_deactivate &= ~DEACTIVATE_ANON; > -- > 2.31.1 >