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

[Michael Ellerman]

David Hildenbrand <david at redhat.com> writes:
> On 01.06.24 08:01, Yu Zhao wrote:
>> On Wed, May 15, 2024 at 4:06 PM Yu Zhao <yuzhao at google.com> wrote:
...
>> 
>> Your system has 2GB memory and it uses zswap with zsmalloc (which is
>> good since it can allocate from the highmem zone) and zstd/lzo (which
>> doesn't matter much). Somehow -- I couldn't figure out why -- it
>> splits the 2GB into a 0.25GB DMA zone and a 1.75GB highmem zone:
>> 
>> [    0.000000] Zone ranges:
>> [    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
>> [    0.000000]   Normal   empty
>> [    0.000000]   HighMem  [mem 0x0000000030000000-0x000000007fffffff]
>
> That's really odd. But we are messing with "PowerMac3,6", so I don't 
> really know what's right or wrong ...

The DMA zone exists because 9739ab7eda45 ("powerpc: enable a 30-bit
ZONE_DMA for 32-bit pmac") selects it.

It's 768MB (not 0.25GB) because it's clamped at max_low_pfn:

#ifdef CONFIG_ZONE_DMA
	max_zone_pfns[ZONE_DMA]	= min(max_low_pfn,
				      1UL << (zone_dma_bits - PAGE_SHIFT));
#endif

Which comes eventually from CONFIG_LOWMEM_SIZE, which defaults to 768MB.

I think it's 768MB because the user:kernel split is 3G:1G, and then the
kernel needs some of that 1G virtual space for vmalloc/ioremap/highmem,
so it splits it 768M:256M.

Then ZONE_NORMAL is empty because it is also limited to max_low_pfn:

	max_zone_pfns[ZONE_NORMAL] = max_low_pfn;

The rest of RAM is highmem.

So I think that's all behaving as expected, but I don't know 32-bit /
highmem stuff that well so I could be wrong.

cheers