linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Down <chris@chrisdown.name>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com,
	akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/4] mm, memcg: reset memcg's memory.{min, low} for reclaiming itself
Date: Tue, 17 Dec 2019 14:20:50 +0000	[thread overview]
Message-ID: <20191217142050.GA131030@chrisdown.name> (raw)
In-Reply-To: <1576582159-5198-4-git-send-email-laoar.shao@gmail.com>

Hi Yafang,

Yafang Shao writes:
>memory.{emin, elow} are set in mem_cgroup_protected(), and the values of
>them won't be changed until next recalculation in this function. After
>either or both of them are set, the next reclaimer to relcaim this memcg
>may be a different reclaimer, e.g. this memcg is also the root memcg of
>the new reclaimer, and then in mem_cgroup_protection() in get_scan_count()
>the old values of them will be used to calculate scan count, that is not
>proper. We should reset them to zero in this case.

If the memcg in question is passed as "root" to mem_cgroup_protected with a 
child as the new "memcg" argument, then I still don't see what is wrong. 
mem_cgroup_protected must be called top-down from the root of the hierarchy in 
order to work already, which we already do in shrink_node_memcgs. This will 
already update the tree's cached effective protections properly, as far as I 
can see.

As such I'm not sure I understand what you mean in the changelog or in the 
patch. emin/elow as a mechanism is already intended to be racy/best-effort, 
since by the time we get to doing work it's always possible that reclaim 
eligibility state changed, and callers have to consider that.

Could you please explain further the situation you're trying to guard against? 
Thanks.

>Cc: Chris Down <chris@chrisdown.name>
>Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
>---
> mm/memcontrol.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
>diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>index f35fcca..234370c 100644
>--- a/mm/memcontrol.c
>+++ b/mm/memcontrol.c
>@@ -6287,8 +6287,17 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
>
> 	if (!root)
> 		root = root_mem_cgroup;
>-	if (memcg == root)
>+	if (memcg == root) {
>+		/*
>+		 * Reset memory.(emin, elow) for reclaiming the memcg
>+		 * itself.
>+		 */
>+		if (memcg != root_mem_cgroup) {
>+			memcg->memory.emin = 0;
>+			memcg->memory.emin = 0;
>+		}
> 		return MEMCG_PROT_NONE;
>+	}
>
> 	usage = page_counter_read(&memcg->memory);
> 	if (!usage)
>-- 
>1.8.3.1
>

  reply	other threads:[~2019-12-17 14:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17 11:29 [PATCH 0/4] memcg, inode: protect page cache from freeing inode Yafang Shao
2019-12-17 11:29 ` [PATCH 1/4] mm, memcg: reduce size of struct mem_cgroup by using bit field Yafang Shao
2019-12-17 11:29 ` [PATCH 2/4] mm, memcg: introduce MEMCG_PROT_SKIP for memcg zero usage case Yafang Shao
2019-12-17 11:29 ` [PATCH 3/4] mm, memcg: reset memcg's memory.{min, low} for reclaiming itself Yafang Shao
2019-12-17 14:20   ` Chris Down [this message]
2019-12-18  1:13     ` Yafang Shao
2019-12-17 11:29 ` [PATCH 4/4] memcg, inode: protect page cache from freeing inode Yafang Shao
2019-12-18  2:21   ` Dave Chinner
2019-12-18  2:33     ` Yafang Shao
2019-12-18 17:53   ` Roman Gushchin
2019-12-19  1:45     ` Yafang Shao
2019-12-17 11:56 ` [PATCH 0/4] " Michal Hocko
2019-12-17 12:19   ` Yafang Shao
2019-12-17 16:54     ` Johannes Weiner
2019-12-18  1:17       ` Yafang Shao
2019-12-18  1:37       ` Andrew Morton
2019-12-18  1:51       ` Dave Chinner
2019-12-18  4:37         ` Johannes Weiner
2019-12-18 10:16           ` Dave Chinner
2019-12-18 21:38             ` Johannes Weiner
2019-12-19  2:04               ` Yafang Shao
2020-01-10  2:08               ` Dave Chinner
2019-12-18 17:27       ` 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=20191217142050.GA131030@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=akpm@linux-foundation.org \
    --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;
as well as URLs for NNTP newsgroup(s).