Message-ID: <c93b217e-1983-1eb1-14ce-8377f94975a1@google.com>
Date: Thu, 21 Dec 2023 20:38:40 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Dan Schatzberg <schatzberg.dan@...il.com>
cc: Johannes Weiner <hannes@...xchg.org>, 
    Roman Gushchin <roman.gushchin@...ux.dev>, 
    Yosry Ahmed <yosryahmed@...gle.com>, Huan Yang <link@...o.com>, 
    linux-kernel@...r.kernel.org, cgroups@...r.kernel.org, linux-mm@...ck.org, 
    Tejun Heo <tj@...nel.org>, Zefan Li <lizefan.x@...edance.com>, 
    Jonathan Corbet <corbet@....net>, Michal Hocko <mhocko@...nel.org>, 
    Shakeel Butt <shakeelb@...gle.com>, Muchun Song <muchun.song@...ux.dev>, 
    Andrew Morton <akpm@...ux-foundation.org>, 
    Kefeng Wang <wangkefeng.wang@...wei.com>, SeongJae Park <sj@...nel.org>, 
    "Vishal Moola (Oracle)" <vishal.moola@...il.com>, 
    Nhat Pham <nphamcs@...il.com>, Yue Zhao <findns94@...il.com>
Subject: Re: [PATCH v5 2/2] mm: add swapiness= arg to memory.reclaim

On Wed, 20 Dec 2023, Dan Schatzberg wrote:

> Allow proactive reclaimers to submit an additional swappiness=<val>
> argument to memory.reclaim. This overrides the global or per-memcg
> swappiness setting for that reclaim attempt.
> 
> For example:
> 
> echo "2M swappiness=0" > /sys/fs/cgroup/memory.reclaim
> 
> will perform reclaim on the rootcg with a swappiness setting of 0 (no
> swap) regardless of the vm.swappiness sysctl setting.
> 
> Userspace proactive reclaimers use the memory.reclaim interface to
> trigger reclaim. The memory.reclaim interface does not allow for any way
> to effect the balance of file vs anon during proactive reclaim. The only
> approach is to adjust the vm.swappiness setting. However, there are a
> few reasons we look to control the balance of file vs anon during
> proactive reclaim, separately from reactive reclaim:
> 
> * Swapout should be limited to manage SSD write endurance. In near-OOM
> situations we are fine with lots of swap-out to avoid OOMs. As these are
> typically rare events, they have relatively little impact on write
> endurance. However, proactive reclaim runs continuously and so its
> impact on SSD write endurance is more significant. Therefore it is
> desireable to control swap-out for proactive reclaim separately from
> reactive reclaim
> 
> * Some userspace OOM killers like systemd-oomd[1] support OOM killing on
> swap exhaustion. This makes sense if the swap exhaustion is triggered
> due to reactive reclaim but less so if it is triggered due to proactive
> reclaim (e.g. one could see OOMs when free memory is ample but anon is
> just particularly cold). Therefore, it's desireable to have proactive
> reclaim reduce or stop swap-out before the threshold at which OOM
> killing occurs.
> 
> In the case of Meta's Senpai proactive reclaimer, we adjust
> vm.swappiness before writes to memory.reclaim[2]. This has been in
> production for nearly two years and has addressed our needs to control
> proactive vs reactive reclaim behavior but is still not ideal for a
> number of reasons:
> 
> * vm.swappiness is a global setting, adjusting it can race/interfere
> with other system administration that wishes to control vm.swappiness.
> In our case, we need to disable Senpai before adjusting vm.swappiness.
> 
> * vm.swappiness is stateful - so a crash or restart of Senpai can leave
> a misconfigured setting. This requires some additional management to
> record the "desired" setting and ensure Senpai always adjusts to it.
> 
> With this patch, we avoid these downsides of adjusting vm.swappiness
> globally.
> 
> [1]https://www.freedesktop.org/software/systemd/man/latest/systemd-oomd.service.html
> [2]https://github.com/facebookincubator/oomd/blob/main/src/oomd/plugins/Senpai.cpp#L585-L598
> 
> Signed-off-by: Dan Schatzberg <schatzberg.dan@...il.com>

Acked-by: David Rientjes <rientjes@...gle.com>

Powered by blists - more mailing lists