[LTP] [PATCH 1/2] memcg/memcontrol0[34]: Use expected values from the protection model

[Michal Koutný]

Hello. 

On Sat, Sep 26, 2026 at 10:44:53PM +0200, Sebastian Chlad <sebastianchlad@gmail.com> wrote:
> From: Sebastian Chlad <sebastian.chlad@suse.com>
> 
> memcontrol03 (memory.min) and memcontrol04 (memory.low) still expect
> A/B/C ~= 33M and A/B/D ~= 17M after reclaim, which are the values from
> the original kselftest. These were never derived from how the kernel
> distributes protection among siblings, and the kselftest replaced them
> with simulated values for both tests in kernel commit f10b6e9a8e66
> ("selftests: memcg: adjust expected reclaim values of protected
> cgroups"):
> 
>   A/B/C  memory.current ~= 29M
>   A/B/D  memory.current ~= 21M
> 
> (see tools/testing/selftests/cgroup/memcg_protection.m for the model).
> 
> Real kernels match the model,

Note: this was true at the time of the model introduction but the
contemporary kernels may diverge slightly from it. (Not conceptually
AFAIR, although some rounding / effective values caching could possibly
affect the final values.)

> so the old D target leaves very little
> room below the upper bound of the 20% tolerance. On 6.12 x86_64, 105
> iterations of memcontrol03 across ext2, ext3, ext4, xfs and btrfs gave:
> 
>   A/B/C  27.5M - 27.9M  (old range 22.0M - 49.5M)
>   A/B/D  22.7M - 23.0M  (old range 11.3M - 25.5M)
> 
> so A/B/D is already at ~90% of the old limit and small variations in
> reclaim push it over. Passing runs on 6.4 ppc64le show the same
> picture for both tests (C 22.6M - 32.0M, D 17.6M - 24.2M).
> 
> Switch to the model values. Keep the 20% tolerance, which is already
> at least as wide as the kselftest's; kernel commit d2def68ae06a
> ("selftests: memcg: increase error tolerance of child memory.current
> check in test_memcg_protection()") raised the kselftest tolerances to
> 15% (C) and 20% (D) for the same kind of sporadic failures.

Makes sense to sync this with the kernel variant.
Reviewed-by: Michal Koutný <mkoutny@suse.com>

> This doesn't change the outcome where C is reclaimed far below D while
> the unprotected A/B/F keeps its pagecache (seen e.g. on ppc64le with
> C ~= 6M and F ~= 13M). That is a protection failure the tests should
> keep reporting.

I presume you refer the same reclaim mode "collapse" that was tackled in
7e19705f7 ("memcg/memcontrol04: Fix judgment for recursive_protection")
(there it was only for unexpected events but that could be connected
with the unexpected final F.memory.current). It is nothing new, correct?

Thanks,
Michal