From: Michal Hocko <mhocko@suse.com>
To: Dave Hansen <dave.hansen@intel.com>,
"Huang, Ying" <ying.huang@intel.com>
Cc: Yang Shi <shy828301@gmail.com>, Wei Xu <weixugc@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: memcg reclaim demotion wrt. isolation
Date: Tue, 13 Dec 2022 16:41:10 +0100 [thread overview]
Message-ID: <Y5idFucjKVbjatqc@dhcp22.suse.cz> (raw)
Hi,
I have just noticed that that pages allocated for demotion targets
includes __GFP_KSWAPD_RECLAIM (through GFP_NOWAIT). This is the case
since the code has been introduced by 26aa2d199d6f ("mm/migrate: demote
pages during reclaim"). I suspect the intention is to trigger the aging
on the fallback node and either drop or further demote oldest pages.
This makes sense but I suspect that this wasn't intended also for
memcg triggered reclaim. This would mean that a memory pressure in one
hierarchy could trigger paging out pages of a different hierarchy if the
demotion target is close to full.
I haven't really checked at the current kswapd wake up checks but I
suspect that kswapd would back off in most cases so this shouldn't
really cause any big problems. But I guess it would be better to simply
not wake kswapd up for the memcg reclaim. What do you think?
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8fcc5fa768c0..1f3161173b85 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1568,7 +1568,7 @@ static struct page *alloc_demote_page(struct page *page, unsigned long private)
* Folios which are not demoted are left on @demote_folios.
*/
static unsigned int demote_folio_list(struct list_head *demote_folios,
- struct pglist_data *pgdat)
+ struct pglist_data *pgdat, bool cgroup_reclaim)
{
int target_nid = next_demotion_node(pgdat->node_id);
unsigned int nr_succeeded;
@@ -1589,6 +1589,10 @@ static unsigned int demote_folio_list(struct list_head *demote_folios,
if (list_empty(demote_folios))
return 0;
+ /* local memcg reclaim shouldn't directly reclaim from other memcgs */
+ if (cgroup_reclaim)
+ mtc->gfp_mask &= ~__GFP_RECLAIM;
+
if (target_nid == NUMA_NO_NODE)
return 0;
@@ -2066,7 +2070,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
/* 'folio_list' is always empty here */
/* Migrate folios selected for demotion */
- nr_reclaimed += demote_folio_list(&demote_folios, pgdat);
+ nr_reclaimed += demote_folio_list(&demote_folios, pgdat, cgroup_reclaim(sc));
/* Folios that could not be demoted are still in @demote_folios */
if (!list_empty(&demote_folios)) {
/* Folios which weren't demoted go back on @folio_list for retry: */
--
Michal Hocko
SUSE Labs
next reply other threads:[~2022-12-13 15:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 15:41 Michal Hocko [this message]
2022-12-13 16:14 ` memcg reclaim demotion wrt. isolation Johannes Weiner
2022-12-14 9:42 ` Michal Hocko
2022-12-14 12:40 ` Johannes Weiner
2022-12-14 15:29 ` Michal Hocko
2022-12-14 17:40 ` Johannes Weiner
2022-12-15 6:17 ` Huang, Ying
2022-12-15 8:22 ` Johannes Weiner
2022-12-16 3:16 ` Huang, Ying
2022-12-13 22:26 ` Dave Hansen
2022-12-14 9:45 ` Michal Hocko
2022-12-14 2:57 ` Huang, Ying
2022-12-14 9:49 ` Michal Hocko
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=Y5idFucjKVbjatqc@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shy828301@gmail.com \
--cc=weixugc@google.com \
--cc=ying.huang@intel.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