On Wed, Jul 24, 2019 at 09:12:50AM +0200, Philipp Hahn wrote: > Hello Ben, > > Am 24.07.19 um 00:03 schrieb Ben Hutchings: > > On Tue, 2019-07-23 at 15:56 +0200, Philipp Hahn wrote: > > [...] > >> - when the job / session terminates, the directory is deleted by > >> pam_systemd. > >> > >> - but the Linux kernel still uses the CGroup to track kernel internal > >> memory (SLAB objects, pending cache pages, ...?) > >> > >> - inside the kernel the CGroup is marked as "dying", but it is only > >> garbage collected very later on > > [...] > >> I do not know who is at fault here, if it is > >> - the Linux kernel for not freeing those resources earlier > >> - systemd for using CGs in a broken way > >> - someone others fault. > > [...] > > > > I would say this is a kernel bug. I think it's the same problem that > > this patch series is trying to solve: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_ml_linux-2Dkernel_20190611231813.3148843-2D1-2Dguro-40fb.com_&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=xNLFAB3gBGB1NCKmQZN-6JNEj_AXfJ3-wYK7IDWJAx4&s=YfWWnoW-zJdTN0hd1tzzZQlUIUtjv-iBN9Co5rNP5J0&e= > > > > Does the description there seem to match what you're seeing? > > Yes, Roman Gushchin replied to me by private mail, which I will quote > here to get his response archived in Debian's BTS as well: > > > Hi Philipp! > > > > Thank you for the report! > > > > I've spent lot of time working on this problem, and the final patchset > > has been merged into 5.3. It implements reparenting of the slab memory > > on cgroup deletion. 5.3 should be much better in reclaiming dying cgroups. > > > > Unfortunately, the patchset is quite invasive and is based on some > > vmstats changes from 5.2, so it's not trivial to backport it to > > older kernels. > > > > Also, there is no good workaround, only manually dropping kernel > > caches or disable the kernel memory accounting as a whole. > > > > Thanks! > > > 段熊春 <duanxiongchun@xxxxxxxxxxxxx> also replied and pointed out his > patch-set <https://patchwork.kernel.org/cover/10772277/>, which solved > the problem for them. I more looks like a "hack", was never applied > upstream as Romans work solved the underlying problem. > > > So should someone™ bite the bullet and try to backport Romans change to > 4.19 (and 4.9)? (those are the kernel versions used by Debian). > I'm not a kernel expert myself, especially no mm/cg expert, but have > done some work myself in the past, but I would happily pass on the > chalice to someone more experienced. Hi Philipp! It's doable from the technical point of view, but I really doubt it's suitable for the official stable. The backport will consist of at least 20+ core mm/memcontrol patches, so it really feels excessive. If you still want to try, you need to backport 205b20cc5a99 first (and the rest of the patchset), but it may also depend on some other vmstat changes. Thanks!
