On Thu, 6 Jun 2024 09:24:56 +0200 "Vlastimil Babka (SUSE)" <vbabka@xxxxxxxxxx> 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
Attachment:
dmesg_610-rc2_g4_lru
Description: Binary data
