kswapd0: page allocation failure: order:0, mode:0x820(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0 (Kernel v6.5.9, 32bit ppc)

[Vlastimil Babka (SUSE)]

On 6/6/24 1:41 AM, Yosry Ahmed wrote:
> On Wed, Jun 5, 2024 at 4:04 PM Erhard Furtner <erhard_f at mailbox.org> wrote:
> 
> I am personally leaning toward (c), but I want to hear the opinions of
> other people here. Yu, Vlastimil, Johannes, Nhat? Anyone else?

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.

> In the long-term, I think we may want to address the lock contention
> in zsmalloc itself instead of zswap spawning multiple zpools.
> 
>>
>> The patch did not apply cleanly on v6.9.3 so I applied it on v6.10-rc2. dmesg of the current v6.10-rc2 run attached.
>>
>> Regards,
>> Erhard
>