From: Michal Hocko <mhocko@kernel.org>
To: Fam Zheng <zhengfeiran@bytedance.com>
Cc: "Yang Shi" <shy828301@gmail.com>,
cgroups@vger.kernel.org, "Linux MM" <linux-mm@kvack.org>,
tj@kernel.org, "Johannes Weiner" <hannes@cmpxchg.org>,
lizefan@huawei.com, "Vladimir Davydov" <vdavydov.dev@gmail.com>,
duanxiongchun@bytedance.com, 张永肃 <zhangyongsu@bytedance.com>,
liuxiaozhou@bytedance.com
Subject: Re: memory cgroup pagecache and inode problem
Date: Wed, 16 Jan 2019 08:06:14 +0100 [thread overview]
Message-ID: <20190116070614.GG24149@dhcp22.suse.cz> (raw)
In-Reply-To: <C7C72217-D4AF-474C-A98E-975E389BC85C@bytedance.com>
On Wed 16-01-19 11:52:08, Fam Zheng wrote:
[...]
> > This is what force_empty is supposed to do. But, as your test shows
> > some page cache may still remain after force_empty, then cause offline
> > memcgs accumulated. I haven't figured out what happened. You may try
> > what Michal suggested.
>
> None of the existing patches helped so far, but we suspect that the
> pages cannot be locked at the force_empty moment. We have being
> working on a “retry” patch which does solve the problem. We’ll
> do more tracing (to have a better understanding of the issue) and post
> the findings and/or the patch later. Thanks.
Just for the record. There was a patch to remove
MEM_CGROUP_RECLAIM_RETRIES restriction in the path. I cannot find the
link right now but that is something we certainly can do. The context is
interruptible by signal and it from my experience any retry count can
lead to unexpected failures. But I guess you really want to check
vmscan tracepoints to see why you cannot reclaim pages on memcg LRUs
first.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-01-16 7:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <15614FDC-198E-449B-BFAF-B00D6EF61155@bytedance.com>
2019-01-04 4:44 ` memory cgroup pagecache and inode problem Fam Zheng
2019-01-04 5:00 ` Yang Shi
2019-01-04 5:12 ` Fam Zheng
2019-01-04 19:36 ` Yang Shi
2019-01-07 5:10 ` Fam Zheng
2019-01-07 8:53 ` Michal Hocko
2019-01-07 9:01 ` Fam Zheng
2019-01-07 9:13 ` Michal Hocko
2019-01-09 4:33 ` Fam Zheng
2019-01-10 5:36 ` Yang Shi
2019-01-10 8:30 ` Fam Zheng
2019-01-10 8:41 ` Michal Hocko
2019-01-16 0:50 ` Yang Shi
2019-01-16 3:52 ` Fam Zheng
2019-01-16 7:06 ` Michal Hocko [this message]
2019-01-16 21:08 ` Yang Shi
2019-01-16 21:06 ` Yang Shi
2019-01-17 2:41 ` Fam Zheng
2019-01-17 5:06 ` Yang Shi
2019-01-19 3:17 ` 段熊春
2019-01-20 23:15 ` Shakeel Butt
2019-01-20 23:15 ` Shakeel Butt
2019-01-20 23:20 ` Shakeel Butt
2019-01-21 10:27 ` Michal Hocko
2019-01-04 9:04 ` Michal Hocko
2019-01-04 10:02 ` Fam Zheng
2019-01-04 10:12 ` Michal Hocko
2019-01-04 10:35 ` Fam Zheng
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=20190116070614.GG24149@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=duanxiongchun@bytedance.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=liuxiaozhou@bytedance.com \
--cc=lizefan@huawei.com \
--cc=shy828301@gmail.com \
--cc=tj@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=zhangyongsu@bytedance.com \
--cc=zhengfeiran@bytedance.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.