On Tue, Jun 15, 2021 at 5:47 AM Alexey Gladkov <legion@xxxxxxxxxx> wrote: > [...] > > I made the second version of the patch [1], but then I had a conversation > with Eric W. Biederman offlist. He convinced me that it is a bad idea to > change all the values in meminfo to accommodate cgroups. But we agreed > that MemAvailable in /proc/meminfo should respect cgroups limits. This > field was created to hide implementation details when calculating > available memory. You can see that it is quite widely used [2]. > So I want to try to move in that direction. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/legion/linux.git/log/?h=patchset/meminfo/v2.0 > [2] https://codesearch.debian.net/search?q=MemAvailable%3A > Please see following two links on the previous discussion on having per-memcg MemAvailable stat. [1] https://lore.kernel.org/linux-mm/alpine.DEB.2.22.394.2006281445210.855265@xxxxxxxxxxxxxxxxxxxxxxxxx/ [2] https://lore.kernel.org/linux-mm/alpine.DEB.2.23.453.2007142018150.2667860@xxxxxxxxxxxxxxxxxxxxxxxxx/ MemAvailable itself is an imprecise metric and involving memcg makes this metric even more weird. The difference of semantics of swap accounting of v1 and v2 is one source of this weirdness (I have not checked your patch if it is handling this weirdness). The lazyfree and deferred split pages are another source. So, I am not sure if complicating an already imprecise metric will make it more useful.
