From: Roman Gushchin <guro@fb.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: "hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"david@fromorbit.com" <david@fromorbit.com>,
"mhocko@kernel.org" <mhocko@kernel.org>,
"vdavydov.dev@gmail.com" <vdavydov.dev@gmail.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v2 2/5] mm, memcg: introduce MEMCG_PROT_SKIP for memcg zero usage case
Date: Thu, 26 Dec 2019 21:36:23 +0000 [thread overview]
Message-ID: <20191226213619.GB22734@tower.dhcp.thefacebook.com> (raw)
In-Reply-To: <1577174006-13025-3-git-send-email-laoar.shao@gmail.com>
On Tue, Dec 24, 2019 at 02:53:23AM -0500, Yafang Shao wrote:
> If the usage of a memcg is zero, we don't need to do useless work to scan
> it. That is a minor optimization.
The optimization isn't really related to the main idea of the patchset,
so I'd prefer to treat it separately.
>
> Cc: Roman Gushchin <guro@fb.com>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> ---
> include/linux/memcontrol.h | 1 +
> mm/memcontrol.c | 2 +-
> mm/vmscan.c | 6 ++++++
> 3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 612a457..1a315c7 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -54,6 +54,7 @@ enum mem_cgroup_protection {
> MEMCG_PROT_NONE,
> MEMCG_PROT_LOW,
> MEMCG_PROT_MIN,
> + MEMCG_PROT_SKIP, /* For zero usage case */
> };
>
> struct mem_cgroup_reclaim_cookie {
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index c5b5f74..f35fcca 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6292,7 +6292,7 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
>
> usage = page_counter_read(&memcg->memory);
> if (!usage)
> - return MEMCG_PROT_NONE;
> + return MEMCG_PROT_SKIP;
I'm concerned that it might lead to a regression with the scraping of
last pages from a memcg. Charge is batched using percpu stocks, so the
value of the page counter is approximate. Skipping the cgroup entirely
we're losing all chances to reclaim these few pages.
Idk how serious the problem could be in the real life, and maybe it's OK
to skip if the cgroup is online, but I'd triple check here.
Also, because this optimization isn't really related to protection,
why not check the page counter first, e.g.:
memcg = mem_cgroup_iter(root, NULL, NULL);
do {
unsigned long reclaimed;
unsigned long scanned;
if (!page_counter_read(&memcg->memory))
continue;
switch (mem_cgroup_protected(root, memcg)) {
case MEMCG_PROT_MIN:
/*
* Hard protection.
* If there is no reclaimable memory, OOM.
*/
continue;
case MEMCG_PROT_LOW:
--
Thank you!
next prev parent reply other threads:[~2019-12-26 21:36 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-24 7:53 [PATCH v2 0/5] protect page cache from freeing inode Yafang Shao
2019-12-24 7:53 ` [PATCH v2 1/5] mm, memcg: reduce size of struct mem_cgroup by using bit field Yafang Shao
2019-12-26 21:23 ` Roman Gushchin
2019-12-27 1:03 ` Yafang Shao
2019-12-24 7:53 ` [PATCH v2 2/5] mm, memcg: introduce MEMCG_PROT_SKIP for memcg zero usage case Yafang Shao
2019-12-26 21:36 ` Roman Gushchin [this message]
2019-12-27 1:09 ` Yafang Shao
2019-12-24 7:53 ` [PATCH v2 3/5] mm, memcg: reset memcg's memory.{min, low} for reclaiming itself Yafang Shao
2019-12-26 21:45 ` Roman Gushchin
2019-12-27 1:11 ` Yafang Shao
2019-12-24 7:53 ` [PATCH v2 4/5] mm: make memcg visible to lru walker isolation function Yafang Shao
2020-01-04 3:35 ` Dave Chinner
2020-01-04 7:26 ` Yafang Shao
2020-01-04 21:23 ` Dave Chinner
2020-01-05 1:43 ` Yafang Shao
2020-01-06 0:17 ` Dave Chinner
2020-01-06 14:41 ` Yafang Shao
2020-01-06 21:31 ` Dave Chinner
2020-01-07 13:22 ` Yafang Shao
2019-12-24 7:53 ` [PATCH v2 5/5] memcg, inode: protect page cache from freeing inode Yafang Shao
2019-12-25 13:01 ` kbuild test robot
2019-12-25 13:18 ` kbuild test robot
2019-12-26 5:09 ` Yafang Shao
2020-01-04 3:55 ` Dave Chinner
2020-01-04 7:42 ` Yafang Shao
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=20191226213619.GB22734@tower.dhcp.thefacebook.com \
--to=guro@fb.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hannes@cmpxchg.org \
--cc=laoar.shao@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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