Re: [PATCH v3 1/6] btrfs: use an on-stack path in btrfs_insert_orphan_item()

[David Sterba]

On Fri, Aug 21, 2026 at 07:43:53AM +0930, Qu Wenruo wrote:
> I think you're very inconsistent on on-stack memory usage at least.
> 
> You were fine when I was adding 128bytes for several call sites for the 
> support of huge pages, and I'd argue all those call sites have a deeper 
> stack, because it's on the writeback path.

This is a different structure and different use case than the
btrfs_path. I'm not happy to allocate 128 bytes but there's no other
way, because during writeback allocating memory is risky and making
things worse. And I'm especially watching out for the path on-stack
conversions because they're too tempting to do. For other structures
it's case by case.

> Furthermore, that huge page support is not widely used, but everyone 
> will need to pay that on-stack price.

Huge pages are a performance optimization and it's good that they're
built in ready to be used when needed and not optional. One clear
benefit is fewer TLB misses, large data processing applications like
databases like that, and there are certaily others.  That we allow such
feature at a known cost is fine by me.

> On the other hand, you are also very hesitant on my recent patches 
> removing those 128 bytes usages.

That's the 'paddr' patchset? This has been merged, I don't have problem
with that.

> So your behavior doesn't seem to match what you said here.
> 
> 
> Secondly, your deep-in-the-stack argument doesn't sound solid either.
> 
> Every block file system can be built upon layer of storage stacks, not 
> only btrfs, but *every* block fs as long as there is a chance to do IO.
> This means you're just saying, there can be almost-infinite lower layers 
> under us, so we should not use any extra on-stack memory.

I think you've extrapolated too far, I'm not saying anything like that.
We have to use stack, but it's a constrained resource. If system has
terabytes of memory we still have 16K of stack per task. Since ever
we've been avoiding unnecessary use, there's an optional kernel build
tool to check for excessive use per function, but it cannot see runtime
effects.

For that there's CONFIG_DEBUG_STACK_USAGE, I have it enabled on my
testing setups. Some sample numbers below.

> I do not think this is the sane nor really validated.

It is indeed not sane to assume infinite layers in the IO stack. What I
consider sane and realistic was written in my reply to Jeff, NFS, iscsi,
encryption, DM/MD block device grouping and lowest level drivers.
Leaving enough space for these layers is a courtesy of filesystem and we
as filesystem expect the same from other layers.  The effects of stack
savings are cumulative and preventative.

> If you want to argue if the extra 112 bytes is good or not, give me some 
> data about the on-stack memory usage.

>From a VM log, doing some dt, fsx tests, no layering:

[    4.625550] mount (62) used greatest stack depth: 12152 bytes left
[    4.754313] mkdir (67) used greatest stack depth: 11736 bytes left
[   13.243415] modprobe (85) used greatest stack depth: 11216 bytes left
[    3.326249] mount (64) used greatest stack depth: 12152 bytes left
[    4.534019] dircolors (91) used greatest stack depth: 11952 bytes left
[   10.640649] tmux (104) used greatest stack depth: 11824 bytes left
[    3.674336] mount (65) used greatest stack depth: 12152 bytes left
[    3.826533] grep (73) used greatest stack depth: 12064 bytes left
[  205.946252] modprobe (151) used greatest stack depth: 11216 bytes left
[  808.970673] dt (187) used greatest stack depth: 10392 bytes left
[  808.971605] dt (184) used greatest stack depth: 9936 bytes left
[ 1006.541586] kworker/u16:12 (201) used greatest stack depth: 8712 bytes left
[    3.736577] mount (64) used greatest stack depth: 12152 bytes left
[    3.877472] grep (73) used greatest stack depth: 11600 bytes left
[    3.751221] mount (62) used greatest stack depth: 12152 bytes left
[    3.683467] mount (62) used greatest stack depth: 12152 bytes left
[    3.735522] mkdir (67) used greatest stack depth: 12064 bytes left
[  393.206022] modprobe (108) used greatest stack depth: 11216 bytes left
[    4.765551] mount (63) used greatest stack depth: 12152 bytes left
[   30.059666] modprobe (109) used greatest stack depth: 11216 bytes left
[    4.445938] mount (62) used greatest stack depth: 12152 bytes left
[   26.977347] modprobe (110) used greatest stack depth: 11216 bytes left
[    7.119540] mount (64) used greatest stack depth: 12152 bytes left
[    7.849920] grep (73) used greatest stack depth: 11496 bytes left
[    3.606916] mount (63) used greatest stack depth: 12152 bytes left
[    4.504006] chmod (76) used greatest stack depth: 12096 bytes left
[   36.783062] modprobe (109) used greatest stack depth: 11512 bytes left
[  425.057076] fsx.real (3720) used greatest stack depth: 10672 bytes left
[ 3019.822458] kworker/u16:5 (3688) used greatest stack depth: 10576 bytes left
[53621.495082] fsx.real (4015) used greatest stack depth: 10464 bytes left

As a base it's 4-6K for filesystem.

> With the proof that with enough stacked dm layer, that extra 112 bytes 
> are going to cause problem.

In the right combination of configuration and system load it can become
a problem.

> Not to mention I believe some dm drivers are queuing the real submission 
> handling into a workqueue, avoiding further increasing the on-stack 
> memory usage.

Yes, for the same reasons to be nice to other layers (eventually for
performance reasons).

While I don't mind rehearsing some basic kernel knowledge it's a bit
amusing that we have to do it namely for stack usage.