The patch titled
Subject: mm: memcg: allow lowering memory.swap.max below the current usage
has been added to the -mm tree. Its filename is
mm-memcg-allow-lowering-memoryswapmax-below-the-current-usage.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-memcg-allow-lowering-memoryswapmax-below-the-current-usage.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-allow-lowering-memoryswapmax-below-the-current-usage.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Tejun Heo <tj@xxxxxxxxxx>
Subject: 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.
Link: http://lkml.kernel.org/r/20180523185041.GR1718769@xxxxxxxxxxxxxxxxxxxxxxxxxxx
Signed-off-by: Tejun Heo <tj@xxxxxxxxxx>
Acked-by: Roman Gushchin <guro@xxxxxx>
Acked-by: Rik van Riel <riel@xxxxxxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxxxx>
Cc: Shaohua Li <shli@xxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
Documentation/cgroup-v2.txt | 5 +++++
mm/memcontrol.c | 6 +-----
2 files changed, 6 insertions(+), 5 deletions(-)
diff -puN Documentation/cgroup-v2.txt~mm-memcg-allow-lowering-memoryswapmax-below-the-current-usage Documentation/cgroup-v2.txt
--- a/Documentation/cgroup-v2.txt~mm-memcg-allow-lowering-memoryswapmax-below-the-current-usage
+++ a/Documentation/cgroup-v2.txt
@@ -1245,6 +1245,11 @@ PAGE_SIZE multiple when read back.
because of running out of swap system-wide or max
limit.
+ 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
~~~~~~~~~~~~~~~~
diff -puN mm/memcontrol.c~mm-memcg-allow-lowering-memoryswapmax-below-the-current-usage mm/memcontrol.c
--- a/mm/memcontrol.c~mm-memcg-allow-lowering-memoryswapmax-below-the-current-usage
+++ a/mm/memcontrol.c
@@ -6354,11 +6354,7 @@ static ssize_t swap_max_write(struct ker
if (err)
return err;
- mutex_lock(&memcg_max_mutex);
- err = page_counter_set_max(&memcg->swap, max);
- mutex_unlock(&memcg_max_mutex);
- if (err)
- return err;
+ xchg(&memcg->swap.max, max);
return nbytes;
}
_
Patches currently in -mm which might be from tj@xxxxxxxxxx are
mm-memcontrol-move-swap-charge-handling-into-get_swap_page.patch
mm-memcontrol-implement-memoryswapevents.patch
mm-memcg-allow-lowering-memoryswapmax-below-the-current-usage.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
