Received-SPF: pass (google.com: domain of linux-kernel+bounces-204742-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <e1b78d49-72ef-4c9e-be1c-919a72940b1b@kernel.org>
Date: Thu, 6 Jun 2024 18:53:36 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: kswapd0: page allocation failure: order:0,
 mode:0x820(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0 (Kernel
 v6.5.9, 32bit ppc)
Content-Language: en-US
To: Erhard Furtner <erhard_f@mailbox.org>
Cc: Yosry Ahmed <yosryahmed@google.com>, Yu Zhao <yuzhao@google.com>,
 linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 linuxppc-dev@lists.ozlabs.org, Johannes Weiner <hannes@cmpxchg.org>,
 Nhat Pham <nphamcs@gmail.com>, Chengming Zhou <chengming.zhou@linux.dev>,
 Sergey Senozhatsky <senozhatsky@chromium.org>,
 Minchan Kim <minchan@kernel.org>, Michal Hocko <mhocko@kernel.org>
References: <20240508202111.768b7a4d@yea> <20240515224524.1c8befbe@yea>
 <CAOUHufZ-9NmzOKjLedvZFp0=N0LvRZn77qC6k1WXK+NHtKr=0w@mail.gmail.com>
 <CAOUHufZ36rQc8AfLtRv2QrEareysdvbprAEO5XkcG-FeDOxFLA@mail.gmail.com>
 <20240602200332.3e531ff1@yea> <20240604001304.5420284f@yea>
 <CAJD7tkbCRLdy0vD2Pd17fNrxHgkzW1VucN4qMkohLFLBLaaeCQ@mail.gmail.com>
 <20240604134458.3ae4396a@yea>
 <CAJD7tkYjJJGthQ_8NukGw6Q9EYbLA=8sAH_7=B90KXEL6HWdSw@mail.gmail.com>
 <CAOUHufa0Fpj6SjNgB-z0n5Jg63q1ewkbOAU65forpDwQVs45qg@mail.gmail.com>
 <CAJD7tkb=5GJ9SNUwDsu1Zy3Tus4rjsNo60Hg9N7=gGth409Diw@mail.gmail.com>
 <CAOUHufb6zXr14Wm3T-4-OJh7iAq+vzDKwVYfHLhMMt96SpiZXg@mail.gmail.com>
 <CAJD7tkZ+QY55GTzW9A7ZCm=rxAEfrW76cWXf8o5nwiKSXp8z=w@mail.gmail.com>
 <20240604231019.18e2f373@yea>
 <CAJD7tkYq5u7B+0UH2XKpeWJnUxoO2kJ1_XZ2JOgYpyNEVR7u0g@mail.gmail.com>
 <20240606010431.2b33318c@yea>
 <CAJD7tkbhWYzx=6YmzAh0F+cK-_Bn8mPOH7gMbQS7YVXmaFSgFg@mail.gmail.com>
 <fd7fafb9-09be-48b1-ba52-57e52c6d973a@kernel.org>
 <20240606153210.18ef5299@yea>
From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
In-Reply-To: <20240606153210.18ef5299@yea>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 6/6/24 3:32 PM, Erhard Furtner wrote:
> On Thu, 6 Jun 2024 09:24:56 +0200
> "Vlastimil Babka (SUSE)" <vbabka@kernel.org> wrote:
> 
>> Besides the zpool commit which might have just pushed the machine over the
>> edge, but it was probably close to it already. I've noticed a more general
>> problem that there are GFP_KERNEL allocations failing from kswapd. Those
>> could probably use be __GFP_NOMEMALLOC (or scoped variant, is there one?)
>> since it's the case of "allocating memory to free memory". Or use mempools
>> if the progress (success will lead to freeing memory) is really guaranteed.
>> 
>> Another interesting data point could be to see if traditional reclaim
>> behaves any better on this machine than MGLRU. I saw in the config:
>> 
>> CONFIG_LRU_GEN=y
>> CONFIG_LRU_GEN_ENABLED=y
>> 
>> So disabling at least the second one would revert to the traditional reclaim
>> and we could see if it handles such a constrained system better or not.
> 
> I set RANDOM_KMALLOC_CACHES=n and LRU_GEN_ENABLED=n but still hit the issue.
> 
> dmesg looks a bit different (unpatched v6.10-rc2).

What caught my eye, but it's also in some of the previous dmesg with MGRLU,
is that in one case there's:

DMA free:0kB

That means many allocations went through that are allowed to just ignore all
reserves, and depleted everything. That would mean __GFP_MEMALLOC or
PF_MEMALLOC, which I suggested earlier for the GFP_KERNEL failure, is being
used somewhere, but not leading to the expected memory freeing.

> Regards,
> Erhard