After further investigation, I found that the observed behavior is expected and consistent with how cgroups work in conjunction with the Linux memory management subsystem.
The leak-memory tool used to reproduce the issue reports the virtual memory (total-vm) reserved by the process. This memory is obtained via malloc() to reserve virtual address space. However, this does not immediately result in physical memory allocation. Physical memory (i.e., pages backed by RAM) is only mapped and charged when the process actually accesses the memory, typically by writing to it. The memory cgroup limit (memory.max) constrains physical memory usage, not virtual address space. In particular, it limits the amount of memory that can be resident in RAM and charged to the cgroup. This corresponds to the anon-rss value, which only increases when pages are physically committed. Therefore, a process can reserve large amounts of virtual memory (high total-vm) without violating the memory cgroup limit, as long as it does not access enough of it to exceed the anon-rss budget. What happens when running the tool is that initially both total-vm and anon-rss increase together, as pages are allocated and accessed. However, once anon-rss approaches the configured memory.max threshold, the kernel begins to reclaim physical memory in order to stay within the cgroup limit. This may involve reclaiming clean pages or unmapping anonymous pages that are not recently used, and ultimately, if the memory pressure cannot be relieved, the kernel invokes the OOM killer for the offending process. In order to show this I modified the leak-memory tool to make it print also other statistics about the memory used. The diff containing the changes I made to leak-memory will be attached to this comment in a .diff. Running the modified version using the command: $ systemd-run --scope -p MemoryMax=50M --user ./leak-memory It is possible to see the behavior described above: [*] ==Allocation== VmSize: 3780 kB RssAnon: 1024 kB RssFile: 1468 kB RssShmem: 0 kB VmPTE: 48 kB ... [*] ==Allocation== VmSize: 35648 kB RssAnon: 32896 kB RssFile: 1596 kB RssShmem: 0 kB VmPTE: 112 kB ... [*] ==Allocation== VmSize: 53124 kB RssAnon: 50432 kB RssFile: 1596 kB RssShmem: 0 kB VmPTE: 148 kB ... [*] ==Allocation== VmSize: 103496 kB RssAnon: 50304 kB RssFile: 1596 kB RssShmem: 0 kB VmPTE: 244 kB ... Changing the memory.max limit will also change the final value of RssAnon. Given this I will mark the bug as "Invalid". ** Patch added: "leak-memory.diff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2105866/+attachment/5869057/+files/leak-memory.diff ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2105866 Title: cgroup: weird calculation for memory limit To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2105866/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
