Re: [Lsf-pc] [LSF/MM/BPF Topic] Performance improvement for Memory Cgroups

[Christian Brauner <brauner@kernel.org>]

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@linux.dev/
> [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@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc