Re: [PATCH 0/4] Delayed ref root cleanups

[Boris Burkov <boris@bur.io>]

On Fri, Jan 09, 2026 at 10:09:21PM +0100, David Sterba wrote:
> On Fri, Jan 09, 2026 at 10:16:27AM -0800, Boris Burkov wrote:
> > On Fri, Jan 09, 2026 at 06:17:39PM +0100, David Sterba wrote:
> > > Embed delayed root into btrfs_fs_info.
> > 
> > The patches all look fine to me, but I think it would be nice to give
> > some justification for why it is desirable to make this change besides
> > "it's possible". If anything, it is a regression on the size of struct
> > btrfs_fs_info as you mention in the first patch.
> 
> A regression? That's an unusal way how to look at it and I did not cross
> my mind. The motivation is that the two objects have same lifetime and
> whe have spare bytes in the slab.
> 

Sorry for the slightly hyperbolic language. My point was merely that it
is the main observable outcome. I agree with you that it's not an actual
meaningful regression in any way that we care about today.

All I'm saying is we consider it a minor win (all else being equal) to
shrink structs, so it's only fair to consider growing them a minor
regression.

It can be offset by other benefits and be an attractive choice anyway.

> > If the answer is just that it's simpler and there is no need for a
> > separate allocation, then fair enough. But then why not directly embed
> > all the one-off structures pointed to by fs_info? Like all the global
> > roots, for example. Are they too large? What constitutes too large?
> > Later, when we slowly add stuff to fs_info till it is bigger than 4k,
> > should we undo this patch set? Or look for other, bigger structs to
> > unembed first?
> 
> Fair questions. If we embed everything the fs_info would be say 16K. The
> threshold I'm considering is 4K, which is 4K page on the most common
> architecture x86_64. ARM can be configured to have 4K or 64K on the most
> common setups, so I'm not making it worse by the 4K choice.

Agreed.

> 
> So, if the structure for embedding is small enough not to cross 4K and
> still leave some space then I consider it worth doing. In the case of

All I'm really asking is for some durable explanation why it is that you
consider it worth doing. Your email and patch messages just explained
why it was possible.

Even something like "if a non optional object is smaller than ~X, we
prefer not to use up slab" would be a helpful explanation.

Understanding how you think about these things is important to other
developers so we know what principles to try to follow in our own work.

Otherwise, we are just guessing at your taste preferences, and we can
monkey around and you can clean up after us :). I assume that is not the
most desirable.

> increasing the fs_info by required and small new members (spinlocks,
> atomics, various stats etc) we can first look how to shring the size by
> reordering it. Currently I see there are 97 bytes in holes. Then we can
> look what is used optionally, eg. depends on a mount option and move it
> to a separate structure.
> 
> The delayed root is a core data structure so we will not have to
> separate it again and revert this patchset. What I'd start looking for
> for a separate data structure would be some kind of static
> almost-read-only information, like mount option bits or status flags
> etc.

I mean, it's not impossible to imagine a future where the lower hanging
fruit are exhausted and we are butting up on 4k.

> 
> Also I don't want people to worry about fs_info size when there's
> something new to implement. We have some space to use and I will notice
> if we cross the boundary as I do random checks of the patch effects
> every now and then. This applies to parameters and stack space
> consumption. You may say this is pointless like in the other patchset
> but even on machines with terabytes of memory a kernel thread is still
> limited to 16K of stack and layering subsystems can use substantial
> portions of it. My long term goal is to keep the level the same without
> hindering development.

I won't say pointless, since you're right, there is a point to reducing
stack size. Perhaps the better expression of how I feel about that is
"arbitrary". But individual improvements are always useful.

Thanks,
Boris