On Tue, Mar 18, 2025 at 11:19:42PM -0700, Shakeel Butt wrote: > A bit late but let me still propose a session on topics related to memory > cgroups. Last year at LSFMM 2024, we discussed [1] about the potential > deprecation of memcg v1. Since then we have made very good progress in that > regard. We have moved the v1-only code in a separate file and make it not > compile by default, have added warnings in many v1-only interfaces and have > removed a lot of v1-only code. This year, I want to focus on performance of > memory cgroup, particularly improving cost of charging and stats. > > At the high level we can partition the memory charging in three cases. First > is the user memory (anon & file), second if kernel memory (slub mostly) and > third is network memory. For network memory, [1] has described some of the > challenges. Similarly for kernel memory, we had to revert patches where memcg > charging was too expensive [3,4]. > > I want to discuss and brainstorm different ways to further optimize the > memcg charging for all these types of memory. I am at the moment prototying > multi-memcg support for per-cpu memcg stocks and would like to see what else > we can do. > > One additional interesting observation from our fleet is that the cost of > memory charging increases for the users of memory.low and memory.min. Basically > propagate_protected_usage() becomes very prominently visible in the perf > traces. > > Other than charging, the memcg stats infra also is very expensive and a lot IIrcu, it also slows down opening files significantly as we discussed last year. So I'm very interested in improvements in this area as well. > of CPUs in our fleet are spent on maintaining these stats. Memcg stats use > rstat infrastructure which is designed for fast updates and slow readers. > The updaters put the cgroup in a per-cpu update tree while the stats readers > flushes update trees of all the cpus. For memcg, the flushes has become very > expensive and over the years we have added ratelimiting to limit the cost. > I want to discuss what else we can do to further improve the memcg stats. > > Other than the performance of charging and memcg stats, time permitting, we > can discuss other memcg topics like new features or something still lacking. > > [1] https://lwn.net/Articles/974575/ > [2] https://lore.kernel.org/all/20250307055936.3988572-1-shakeel.butt@xxxxxxxxx/ > [3] 3754707bcc3e ("Revert "memcg: enable accounting for file lock caches"") > [4] 0bcfe68b8767 ("Revert "memcg: enable accounting for pollfd and select bits arrays"") > _______________________________________________ > Lsf-pc mailing list > Lsf-pc@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc
