Re: [QUESTION] Order-4 allocation failures on reads with 256bit csums

[Hillf Danton <hdanton@sina.com>]

On Thursday 11/06 at 07:31 +1030, Qu Wenruo wrote:
> 在 2025/11/6 07:24, Qu Wenruo 写道:
> > 在 2025/11/6 04:30, Calvin Owens 写道:
> > > Hello all,
> > > 
> > > I'm seeing order-4 allocation failures reading from btrfs filesystems
> > > with blake2b/sha256 checksums, on a couple different machines.
> > > 
> > > I don't think I'm doing anything interesting: in both cases they were
> > > idle except for a single-threaded file reader doing buffered I/O. The
> > > first one was an x86 QEMU VM, the second was a raspberry pi 4b (below):
> 
> Another thing is, although the order 4 allocation is indeed large, it's not
> that unreasonable large.
> 
> The problem is still that we're requiring physically contiguous range which
> greatly reduce the chance to get one.
> 
> Another point contributing to this is the order 4, which is beyond the
> PAGE_ALLOC_COSTLY_ORDER (3), thus no more retry is done thus can fail here.
> 
And the flag GFP_NOFS, though correct, in this report that makes any high order insane.

> In fact for your aarch64 case, you can configure the kernel to use 64K page
> size and in that case such allocation will only be one page thus will almost
> never fail.
>
> This leads to my final question, what's the memory size of the RPI4 and your
> qemu VM?
> My guess is there is a very limited amount of memory (1GiB?), but still a
> lot of large buffered IOs.
> I guess enlarging the VM RAM size will hugely reduce the chance of memory
> allocation failure.