2018-05-23 18:52:27

by Tejun Heo

[permalink] [raw]
Subject: [PATCH REPOST] mm: memcg: allow lowering memory.swap.max below the current usage

Currently an attempt to set swap.max into a value lower than the
actual swap usage fails, which causes configuration problems as
there's no way of lowering the configuration below the current usage
short of turning off swap entirely. This makes swap.max difficult to
use and allows delegatees to lock the delegator out of reducing swap
allocation.

This patch updates swap_max_write() so that the limit can be lowered
below the current usage. It doesn't implement active reclaiming of
swap entries for the following reasons.

* mem_cgroup_swap_full() already tells the swap machinary to
aggressively reclaim swap entries if the usage is above 50% of
limit, so simply lowering the limit automatically triggers gradual
reclaim.

* Forcing back swapped out pages is likely to heavily impact the
workload and mess up the working set. Given that swap usually is a
lot less valuable and less scarce, letting the existing usage
dissipate over time through the above gradual reclaim and as they're
falted back in is likely the better behavior.

Signed-off-by: Tejun Heo <[email protected]>
Acked-by: Roman Gushchin <[email protected]>
Acked-by: Rik van Riel <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Shaohua Li <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
Hello, Andrew.

This was buried in the thread discussing Roman's original patch. The
consensus seems to be that this simple approach is what we wanna do at
least for now. Can you please pick it up?

Thanks.

Documentation/cgroup-v2.txt | 5 +++++
mm/memcontrol.c | 6 +-----
2 files changed, 6 insertions(+), 5 deletions(-)

--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -1199,6 +1199,11 @@ PAGE_SIZE multiple when read back.
Swap usage hard limit. If a cgroup's swap usage reaches this
limit, anonymous memory of the cgroup will not be swapped out.

+ When reduced under the current usage, the existing swap
+ entries are reclaimed gradually and the swap usage may stay
+ higher than the limit for an extended period of time. This
+ reduces the impact on the workload and memory management.
+

Usage Guidelines
~~~~~~~~~~~~~~~~
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6144,11 +6144,7 @@ static ssize_t swap_max_write(struct ker
if (err)
return err;

- mutex_lock(&memcg_limit_mutex);
- err = page_counter_limit(&memcg->swap, max);
- mutex_unlock(&memcg_limit_mutex);
- if (err)
- return err;
+ xchg(&memcg->swap.limit, max);

return nbytes;
}


2018-05-24 10:57:13

by Johannes Weiner

[permalink] [raw]
Subject: Re: [PATCH REPOST] mm: memcg: allow lowering memory.swap.max below the current usage

On Wed, May 23, 2018 at 11:50:41AM -0700, Tejun Heo wrote:
> Currently an attempt to set swap.max into a value lower than the
> actual swap usage fails, which causes configuration problems as
> there's no way of lowering the configuration below the current usage
> short of turning off swap entirely. This makes swap.max difficult to
> use and allows delegatees to lock the delegator out of reducing swap
> allocation.
>
> This patch updates swap_max_write() so that the limit can be lowered
> below the current usage. It doesn't implement active reclaiming of
> swap entries for the following reasons.
>
> * mem_cgroup_swap_full() already tells the swap machinary to
> aggressively reclaim swap entries if the usage is above 50% of
> limit, so simply lowering the limit automatically triggers gradual
> reclaim.
>
> * Forcing back swapped out pages is likely to heavily impact the
> workload and mess up the working set. Given that swap usually is a
> lot less valuable and less scarce, letting the existing usage
> dissipate over time through the above gradual reclaim and as they're
> falted back in is likely the better behavior.
>
> Signed-off-by: Tejun Heo <[email protected]>
> Acked-by: Roman Gushchin <[email protected]>
> Acked-by: Rik van Riel <[email protected]>
> Cc: Johannes Weiner <[email protected]>
> Cc: Michal Hocko <[email protected]>
> Cc: Shaohua Li <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]

Acked-by: Johannes Weiner <[email protected]>