Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 13 Dec 2022 17:14:48 +0100
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
Message-ID: <Y5ik+CCmvapf87Mb@cmpxchg.org>
References: <Y5idFucjKVbjatqc@dhcp22.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y5idFucjKVbjatqc@dhcp22.suse.cz>
Precedence: bulk

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.