From: Michal Hocko <mhocko@kernel.org>
To: Bruce Merry <bmerry@ska.ac.za>
Cc: "Singh, Balbir" <bsingharora@gmail.com>,
Shakeel Butt <shakeelb@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: Showing /sys/fs/cgroup/memory/memory.stat very slow on some machines
Date: Thu, 26 Jul 2018 10:19:47 +0200 [thread overview]
Message-ID: <20180726081947.GA28386@dhcp22.suse.cz> (raw)
In-Reply-To: <CAOm-9ar2zzxZvZ9A0Yu0knn_LNcHsck72wXShFXutYvAN2qu9Q@mail.gmail.com>
On Thu 26-07-18 08:41:35, Bruce Merry wrote:
> On 26 July 2018 at 02:55, Singh, Balbir <bsingharora@gmail.com> wrote:
> > Do you by any chance have use_hierarch=1? memcg_stat_show should just rely on counters inside the memory cgroup and the the LRU sizes for each node.
>
> Yes, /sys/fs/cgroup/memory/memory.use_hierarchy is 1. I assume systemd
> is doing that.
And this is actually good. Non hierarchical behavior is discouraged.
The real problem is that we are keeping way too many zombie memcgs
around and waiting for memory pressure to reclaim them and so they go
away on their own.
As I've tried to explain in other email force_empty before removing the
memcg should help.
Fixing this properly would require quite some heavy lifting AFAICS. We
would basically have to move zombies out of the way which is not hard
but we do not want to hide their current memory consumption so we would
have to somehow move their stats to the parent. And then we are back to
reparenting which has been removed by b2052564e66d ("mm: memcontrol:
continue cache reclaim from offlined groups").
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2018-07-26 8:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAOm-9arwY3VLUx5189JAR9J7B=Miad9nQjjet_VNdT3i+J+5FA@mail.gmail.com>
2018-07-18 4:23 ` Showing /sys/fs/cgroup/memory/memory.stat very slow on some machines Andrew Morton
2018-07-18 10:42 ` Michal Hocko
2018-07-18 14:29 ` Bruce Merry
2018-07-18 14:47 ` Michal Hocko
2018-07-18 15:27 ` Bruce Merry
2018-07-18 15:33 ` Shakeel Butt
2018-07-18 15:26 ` Shakeel Butt
2018-07-18 15:37 ` Bruce Merry
2018-07-18 15:49 ` Shakeel Butt
2018-07-18 17:40 ` Bruce Merry
2018-07-18 17:48 ` Shakeel Butt
2018-07-18 17:58 ` Bruce Merry
2018-07-18 18:13 ` Shakeel Butt
2018-07-18 18:43 ` Bruce Merry
2018-07-24 10:05 ` Bruce Merry
2018-07-24 10:50 ` Marinko Catovic
2018-07-25 12:29 ` Michal Hocko
2018-07-25 12:32 ` Michal Hocko
2018-07-26 12:35 ` Bruce Merry
2018-07-26 12:48 ` Michal Hocko
2018-07-26 0:55 ` Singh, Balbir
2018-07-26 6:41 ` Bruce Merry
2018-07-26 8:19 ` Michal Hocko [this message]
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=20180726081947.GA28386@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bmerry@ska.ac.za \
--cc=bsingharora@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shakeelb@google.com \
--cc=vdavydov.dev@gmail.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;
as well as URLs for NNTP newsgroup(s).