From: Roman Gushchin <guro@fb.com>
To: "Saeed Karimabadi (skarimab)" <skarimab@cisco.com>
Cc: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
"David Rientjes" <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Tejun Heo <tj@kernel.org>, Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
"xe-linux-external(mailer list)" <xe-linux-external@cisco.com>
Subject: Re: CGroup unused allocated slab objects will not get released
Date: Wed, 18 Sep 2019 22:23:21 +0000 [thread overview]
Message-ID: <20190918222315.GA16105@castle> (raw)
In-Reply-To: <BYAPR11MB2582482E28ACA901B35AF777CC8E0@BYAPR11MB2582.namprd11.prod.outlook.com>
On Wed, Sep 18, 2019 at 08:31:18PM +0000, Saeed Karimabadi (skarimab) wrote:
> Hi Kernel Maintainers,
>
> We are chasing an issue where slab allocator is not releasing task_struct slab objects allocated by cgroups
> and we are wondering if this is a known issue or an expected behavior ?
> If we stress test the system and spawn multiple tasks with different cgroups, number of active allocated
> task_struct objects will increase but kernel will never release those memory later on, even though if system
> goes to the idle state with lower number of the running processes.
Hi Saeed!
I've recently proposed a new slab memory cgroup controller, which aims to solve
the problem you're describing: https://lwn.net/Articles/798605/ . It also generally
reduces the amount of memory used by slabs.
I've been told that not all e-mails in the patchset reached lkml,
so, please, find the original patchset here:
https://github.com/rgushchin/linux/tree/new_slab.rfc
and it's backport to the 5.3 release here:
https://github.com/rgushchin/linux/tree/new_slab.rfc.v5.3
If you can try it on your setup, I'd appreciate it a lot, and it also can
help with merging it upstream soon.
Thank you!
Roman
next prev parent reply other threads:[~2019-09-18 22:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 20:31 CGroup unused allocated slab objects will not get released Saeed Karimabadi (skarimab)
2019-09-18 22:23 ` Roman Gushchin [this message]
2019-09-18 23:48 ` Saeed Karimabadi (skarimab)
2019-09-19 0:33 ` Roman Gushchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190918222315.GA16105@castle \
--to=guro@fb.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=cl@linux.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=mhocko@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=skarimab@cisco.com \
--cc=tj@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=xe-linux-external@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.