[Devel] [PATCH RHEL7 COMMIT] mm/mem_cgroup_iter: Make 'iter->last_visited' a bit more stable
Vasily Averin
vvs at virtuozzo.com
Wed Mar 3 09:25:57 MSK 2021
The commit is pushed to "branch-rh7-3.10.0-1160.15.2.vz7.173.x-ovz" and will appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-1160.15.2.vz7.173.1
------>
commit 3ce75513589f8ced92587e4ae04ef5053cbda438
Author: Konstantin Khorenko <khorenko at virtuozzo.com>
Date: Wed Mar 3 09:25:57 2021 +0300
mm/mem_cgroup_iter: Make 'iter->last_visited' a bit more stable
Patch-set description:
May thanks to Kirill Tkhai for his bright ideas and review!
Problem description from the user point of view:
* the Node is slow
* the Node has a lot of free RAM
* the Node has a lot of swapin/swapout
* kswapd is always running
Problem in a nutshell from technical point of view:
* kswapd is looping in shrink_zone() inside the loop
do {} while ((memcg = mem_cgroup_iter(root, memcg, &reclaim)));
(and never goes trough the outer loop)
* there are a quite a number of memory cgroups of the Node (~1000)
* some cgroups are hard to reclaim (reclaim may take ~3 seconds),
this is because of very busy disk due to permanent swapin/swapout
* mem_cgroup_iter() does not have success scanning all cgroups
in a row, it restarts from the root cgroup one time after
another (after different number of cgroups scanned)
Q: Why does mem_cgroup_iter() restart from the root memcg?
A: Because it is invalidated once some memory cgroup is
destroyed on the Node.
Note: ANY memory cgroup destroy on the Node leads to iter
restart.
The following patchset solves this problem in the following way:
there is no need to restart the iter until we see the iter has
the position which is exactly the memory cgroup being destroyed.
The patchset ensures the iter->last_visited is NULL-ified on
invalidation and thus restarts only in the unlikely case when
the iter points to the memcg being destroyed.
Testing: i've tested this patchset using modified kernel which breaks
the memcg iterator in case of global reclaim with probability of 2%.
3 kernels have been tested: "release", KASAN-only, "debug" kernels.
Each worked for 12 hours, no issues, from 12000 to 26000 races were
caught during this period (i.e. dying memcg was found in some iterator
and wiped).
The testing scenario is documented in the jira issue.
https://jira.sw.ru/browse/PSBM-123655
+++ Current patch description:
In fact this patch does not change the logic, but after it
we can state that iter->last_visited _always_ contains valid
pointer until the iter is "break-ed".
Why? Because 'last_visited' is always assigned in _update()
to the memcg which has passed css_tryget(), so css won't be
ever offlined (and moreover - destroyed) until we css_put() it.
And if now we call css_put() after iter->last_visited is
assigned a new cgroup, the only case when 'last_visited' may
contain invalid entry is "break-ed" mem_cgroup_iter().
https://jira.sw.ru/browse/PSBM-123655
Signed-off-by: Konstantin Khorenko <khorenko at virtuozzo.com>
Reviewed-by: Kirill Tkhai <ktkhai at virtuozzo.com>
---
mm/memcontrol.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 68dfb8f..804d644 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1616,9 +1616,6 @@ static void mem_cgroup_iter_update(struct mem_cgroup_reclaim_iter *iter,
struct mem_cgroup *root,
int sequence)
{
- /* root reference counting symmetric to mem_cgroup_iter_load */
- if (last_visited && last_visited != root)
- css_put(&last_visited->css);
/*
* We store the sequence count from the time @last_visited was
* loaded successfully instead of rereading it here so that we
@@ -1628,6 +1625,10 @@ static void mem_cgroup_iter_update(struct mem_cgroup_reclaim_iter *iter,
iter->last_visited = new_position;
smp_wmb();
iter->last_dead_count = sequence;
+
+ /* root reference counting symmetric to mem_cgroup_iter_load */
+ if (last_visited && last_visited != root)
+ css_put(&last_visited->css);
}
/**
More information about the Devel
mailing list