This is effectively a revert of commit cdc69458a5f3 ("cgroup: account
for memory_recursiveprot in test_memcg_low()"). The case test_memcg_low
will fail with memory_recursiveprot until resolved in reclaim
code.
However, this patch preserves the existing helpers and variables for
later uses.
Signed-off-by: Michal Koutný <[email protected]>
---
tools/testing/selftests/cgroup/test_memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testing/selftests/cgroup/test_memcontrol.c
index 4958b42201a9..eba252fa64ac 100644
--- a/tools/testing/selftests/cgroup/test_memcontrol.c
+++ b/tools/testing/selftests/cgroup/test_memcontrol.c
@@ -528,7 +528,7 @@ static int test_memcg_low(const char *root)
}
for (i = 0; i < ARRAY_SIZE(children); i++) {
- int no_low_events_index = has_recursiveprot ? 2 : 1;
+ int no_low_events_index = 1;
oom = cg_read_key_long(children[i], "memory.events", "oom ");
low = cg_read_key_long(children[i], "memory.events", "low ");
--
2.35.3
On Fri, May 13, 2022 at 07:18:09PM +0200, Michal Koutny wrote:
> This is effectively a revert of commit cdc69458a5f3 ("cgroup: account
> for memory_recursiveprot in test_memcg_low()"). The case test_memcg_low
> will fail with memory_recursiveprot until resolved in reclaim
> code.
Hm, what are our plans here? Are we going to fix it soon-ish, or there
is still no agreement on how to proceed?
On Fri, May 13, 2022 at 07:18:09PM +0200, Michal Koutn? wrote:
> This is effectively a revert of commit cdc69458a5f3 ("cgroup: account
> for memory_recursiveprot in test_memcg_low()"). The case test_memcg_low
> will fail with memory_recursiveprot until resolved in reclaim
> code.
> However, this patch preserves the existing helpers and variables for
> later uses.
>
> Signed-off-by: Michal Koutn? <[email protected]>
> ---
> tools/testing/selftests/cgroup/test_memcontrol.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testing/selftests/cgroup/test_memcontrol.c
> index 4958b42201a9..eba252fa64ac 100644
> --- a/tools/testing/selftests/cgroup/test_memcontrol.c
> +++ b/tools/testing/selftests/cgroup/test_memcontrol.c
> @@ -528,7 +528,7 @@ static int test_memcg_low(const char *root)
> }
>
> for (i = 0; i < ARRAY_SIZE(children); i++) {
> - int no_low_events_index = has_recursiveprot ? 2 : 1;
> + int no_low_events_index = 1;
>
> oom = cg_read_key_long(children[i], "memory.events", "oom ");
> low = cg_read_key_long(children[i], "memory.events", "low ");
> --
> 2.35.3
>
Reviewed-by: David Vernet <[email protected]>
Hi.
On Fri, May 13, 2022 at 11:54:16AM -0700, Roman Gushchin <[email protected]> wrote:
> Hm, what are our plans here? Are we going to fix it soon-ish, or there
> is still no agreement on how to proceed?
Here are some of my ideas in random order so far and comments:
0) mask memory.events:low
-> not a real fix
1) don't do SWAP_CLUSTER_MAX roundup
-> won't solve sudden lift of protection
2) instead of SWAP_CLUSTER_MAX over-reclaim, do same under-reclaim
-> same problem as 1)
3) update children_low_usage transactionally (after reclaim round is done)
- ???
4) don't recursively distribute residual protection in the same reclaim round
- ???
5) iterate siblings from highest to lowest protection
- not a solution
6) assign only >SWAP_CLUSTER_MAX of residuum
- need more info
I'm discouraged by possible complexity of 3) or 4), while 6) is what I'd
like to look more into.
HTH,
Michal