Re: Fwd: btrfs: OOM in split_item().

[David Sterba <dsterba@suse.cz>]

On Wed, Sep 09, 2026 at 06:57:59AM +0930, Qu Wenruo wrote:
> 在 2026/9/8 22:44, David Sterba 写道:
> > On Tue, Sep 08, 2026 at 07:45:58AM +0930, Qu Wenruo wrote:
> >> Forwarded for archive purposes, as patchcheck requires a link: tag
> >> following reported-by: tag.
> >>
> >> Meanwhile the original report is only a private mail to me.
> >>
> >> -------- 转发的消息 --------
> >> 主题: 	btrfs: OOM in split_item().
> >> 日期: 	Mon, 07 Sep 2026 20:10:56 +0000
> >> 发件人: 	xavierbachmeyer182 <xavierbachmeyer182@protonmail.com>
> >> 收件人: 	wqu@suse.com <wqu@suse.com>
> >>
> >>
> >>
> >> Hello.
> >>
> >> Attached is a kernel log entry showing a strange out of memory issue
> >> that rarely seems to happen.
> >> It's kind of annoying and makes me wish GFP_NOFS would go the way of the
> >> dinosaur.
> > 
> > What is the story behind that? One way or another we will get GPF_NOFS
> > semantics, either the flag or the scoped NOFS and this limits the
> > allocator.
> 
> No extra follow up unfortunately.

For the record, as it was in a separate mail, that GFP_NOFS can
sometimes fail because of page fragmentation and limited options for the
allocator.

> > Using 64k nodes is problematic and so I'd rather people not use it on 4k
> > systems.
> 
> In fact the only problematic part in b-tree operation is exactly the 
> vmalloc() I'm fixing.
> 
> Other than that I see no obvious problem related to 64K nodesize on 4K 
> page systems.

Technically if the allocation has a fallback then there's no problem. In
practice the 64K contiguous memory needs to get shifted for almost every
metadata insertion. COW requires the whole 64K set of pages to be
allocated. So there's a lot of dead weight carried around.

It's a tradeoff, 4K nodesize would need taller b-tree for the same
amount of raw items. This is worse due to lock contention and concurrent
changes. I think the 16K is a reasonable middle ground.

> The way we handle metadata is already vmalloc() like, we allocate page 
> sized folios for 64K nodes anyway.

Yeah, that we've been heading towards large folios also means contiguous
ranges for nodes. Memory management is aware of that and allocator
should provides that by the means of compaction. I don't know how much
it could be improved.