From: Calvin Owens <calvin@wbinvd.org>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>
Subject: Re: [QUESTION] Order-4 allocation failures on reads with 256bit csums
Date: Wed, 5 Nov 2025 17:03:31 -0800 [thread overview]
Message-ID: <aQvz42UTgwx7zFrO@mozart.vkv.me> (raw)
In-Reply-To: <0f137e3f-7b9b-4fbe-a8f7-2c90dad1a5fc@suse.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.
>
> 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.
Thanks for looking Qu.
Both have 8GB of RAM, here's the rest of the allocfail trace from the pi
in case it's interesting:
Mem-Info:
active_anon:56 inactive_anon:3262 isolated_anon:0
active_file:421253 inactive_file:1487506 isolated_file:0
unevictable:0 dirty:51 writeback:0
slab_reclaimable:28851 slab_unreclaimable:13163
mapped:6531 shmem:13 pagetables:493
sec_pagetables:0 bounce:0
kernel_misc_reclaimable:0
free:39062 free_pcp:34 free_cma:15
Node 0 active_anon:224kB inactive_anon:13048kB active_file:1685012kB inactive_file:5950024kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:26124kB dirty:204kB writeback:0kB shmem:52kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:0kB kernel_stack:3472kB pagetables:1972kB sec_pagetables:0kB all_unreclaimable? no Balloon:0kB
DMA free:48336kB boost:12288kB min:19692kB low:21540kB high:23388kB reserved_highatomic:2048KB free_highatomic:2032KB active_anon:0kB inactive_anon:80kB active_file:274560kB inactive_file:545700kB unevictable:0kB writepending:0kB present:970752kB managed:880012kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:60kB
lowmem_reserve[]: 0 3008 6962 6962
DMA32 free:53372kB boost:10240kB min:36236kB low:42732kB high:49228kB reserved_highatomic:2048KB free_highatomic:2016KB active_anon:32kB inactive_anon:124kB active_file:971292kB inactive_file:1993632kB unevictable:0kB writepending:24kB present:3080192kB managed:3080192kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 0 3954 3954
Normal free:54540kB boost:16384kB min:50560kB low:59104kB high:67648kB reserved_highatomic:2048KB free_highatomic:2032KB active_anon:192kB inactive_anon:12844kB active_file:439160kB inactive_file:3410608kB unevictable:0kB writepending:180kB present:4194304kB managed:4049512kB mlocked:0kB bounce:0kB free_pcp:136kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 0 0 0
DMA: 12*4kB (UM) 11*8kB (UM) 53*16kB (UMEH) 40*32kB (UMH) 18*64kB (UMH) 47*128kB (UMH) 34*256kB (UMH) 39*512kB (UMH) 10*1024kB (UMH) 0*2048kB 0*4096kB = 48344kB
DMA32: 14*4kB (UME) 16*8kB (UME) 806*16kB (UMEH) 194*32kB (UMEH) 29*64kB (UEH) 50*128kB (UM) 34*256kB (UMEH) 22*512kB (UMH) 4*1024kB (UMH) 1*2048kB (M) 0*4096kB = 53656kB
Normal: 3*4kB (U) 6*8kB (U) 10*16kB (UEH) 31*32kB (UMEH) 35*64kB (UMEH) 45*128kB (UMH) 13*256kB (MH) 74*512kB (MH) 4*1024kB (UH) 0*2048kB 0*4096kB = 54524kB
Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB
Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB
1909321 total pagecache pages
532 pages in swap cache
Free swap = 16764072kB
Total swap = 16777212kB
2061312 pages RAM
0 pages HighMem/MovableOnly
58883 pages reserved
16384 pages cma reserved
next prev parent reply other threads:[~2025-11-06 1:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 18:00 Calvin Owens
2025-11-05 20:54 ` Qu Wenruo
2025-11-05 21:01 ` Qu Wenruo
2025-11-06 1:03 ` Calvin Owens [this message]
2025-11-06 2:34 ` Hillf Danton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQvz42UTgwx7zFrO@mozart.vkv.me \
--to=calvin@wbinvd.org \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®