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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox