tests/int/cgroups: Use 64K aligned limits for memory.max

[donettom-1]

When a non–page-aligned value is written to memory.max, the kernel aligns it down to the nearest page boundary. On systems with a page size greater than 4K (e.g., 64K), this caused failures because the configured memory.max value was not 64K aligned.

This patch fixes the issue by explicitly aligning the memory.max value to 64K. Since 64K is also a multiple of 4K, the value is correctly aligned on both 4K and 64K page size systems.

However, this approach will still fail on systems where the hardcoded memory.max value is not aligned to the system page size.

Fixes: #4841

[ricardobranco777]

Verified to work on:

• aarch64: https://openqa.opensuse.org/tests/5312538
• ppc64le: https://openqa.opensuse.org/tests/5312537
• x86_64: https://openqa.opensuse.org/tests/5312540

Thanks!

[kolyshkin]

LGTM

[rata]

LGTM, thanks a lot for fixing those tests!

[rata]

@donettom-1 One thing I'm not sure I follow is: on systems with 64k page size, the value is round down to a 4k aligned and that is why it fails (it is still not 64k aligned)? Or why is this failing exactly on 64k page-size systems when we write something not 64k aligned?

[donettom-1]

@donettom-1 One thing I'm not sure I follow is: on systems with 64k page size, the value is round down to a 4k aligned and that is why it fails (it is still not 64k aligned)? Or why is this failing exactly on 64k page-size systems when we write something not 64k aligned?

Previously, we were setting the value 20484096 for memory.max. This value is aligned to 4K, but not to 64K. On systems with a 64K page size, the kernel automatically rounds down any non–page size aligned value to the nearest page boundary. As a result, the value 20484096 was adjusted down to 20447232.

When the test read back memory.max, it observed 20447232 instead of the originally written 20484096, causing the mismatch and resulting in the test failure.

[rata]

Ohhh, right! Heh, I'll blame that I wasn't fully awake. Thanks! :)