[LSF/MM/BPF Topic] Performance improvement for Memory Cgroups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
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"")




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux