From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
"Huang, Ying" <ying.huang@intel.com>,
Yang Shi <shy828301@gmail.com>, Wei Xu <weixugc@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: memcg reclaim demotion wrt. isolation
Date: Tue, 13 Dec 2022 17:14:48 +0100 [thread overview]
Message-ID: <Y5ik+CCmvapf87Mb@cmpxchg.org> (raw)
In-Reply-To: <Y5idFucjKVbjatqc@dhcp22.suse.cz>
On Tue, Dec 13, 2022 at 04:41:10PM +0100, Michal Hocko wrote:
> 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.
This is also true if you don't do demotion. If a cgroup tries to
allocate memory on a full node (i.e. mbind()), it may wake kswapd or
enter global reclaim directly which may push out the memory of other
cgroups, regardless of the respective cgroup limits.
The demotion allocations don't strike me as any different. They're
just allocations on behalf of a cgroup. I would expect them to wake
kswapd and reclaim physical memory as needed.
next prev parent reply other threads:[~2022-12-13 16:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 15:41 Michal Hocko
2022-12-13 16:14 ` Johannes Weiner [this message]
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=Y5ik+CCmvapf87Mb@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--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