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

[Qu Wenruo <wqu@suse.com>]

在 2026/9/9 10:14, David Sterba 写道:
> 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.

That is not true, at least not for all cases.

The 64K buffer is only needed when we got a huge item to split. 
Meanwhile the most common cases of btrfs items are all fixed sized.

Some have variable length like DIR items, but name length should not 
exceed 4K either.

The real exceptions are:

- XATTR items
   User can provide a huge XATTR, and the end user may even intentionally
   choose 64K nodesize just for such large XATTR support.

   This should be rare, but I still remember some users are using XATTR
   to store extra checksums.
   But on the other hand, such XATTR should not be split, so nothing to
   bother yet.

- Inline extents
   For 4K sectorsize it's never a problem, even for bs > ps support it's
   not a problem either as we do not allow inlined extent for extent
   larger than 4K.

   But it's still possible to hit a 64K inlined extent if it's created
   on 64K page systems, then mount on 4K page systems.

   It's not only very rare, but also we won't split the item, so again
   not to bother.

- Csum items
   This is the exact case we're hitting.

   The point here is, we can use as large as the whole leaf for a csum
   item.
   This makes split much harder, requiring a huge buffer for such split.

   I think we should introduce an artificial limit on the csum item size.
   Keep it 16K at max should greatly reduce the need for large buffer.
   And the cost is pretty minimal, just extra btrfs_items.
   At most it will be 3 * 25 bytes for 64K node size, I think it's
   definitely acceptable.

   By that, we also reduce the buffer requirement for such csum item
   split.

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

It's a trade-off for nodesize selection, but for this particular csum 
item split, I think we should fix it no matter if you want to prevent 
64K node size or not.

Personally I do not want to discourage any valid nodesize/sectorsize 
combination.

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