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

[Erhard Furtner]

On Thu, 6 Jun 2024 09:24:56 +0200
"Vlastimil Babka (SUSE)" <vbabka at 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).

Regards,
Erhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_610-rc2_g4_lru
Type: application/octet-stream
Size: 42878 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20240606/e2b8a327/attachment-0001.obj>