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

[Qu Wenruo <wqu@suse.com>]

在 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.

> 
> 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.

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