Re: [PATCH 0/8] btrfs: inode management and memory consumption improvements

From: Filipe Manana <fdmanana@kernel.org>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/8] btrfs: inode management and memory consumption improvements
Date: Fri, 10 May 2024 12:04:50 +0100	[thread overview]
Message-ID: <CAL3q7H4EMvqHbYw+FRnM3eKf=AyFx7yNWdfDDw=4638-UTyk7A@mail.gmail.com> (raw)
In-Reply-To: <20240509175633.GO13977@twin.jikos.cz>

On Thu, May 9, 2024 at 6:56 PM David Sterba <dsterba@suse.cz> wrote:
>
> On Wed, May 08, 2024 at 01:17:23PM +0100, fdmanana@kernel.org wrote:
> > From: Filipe Manana <fdmanana@suse.com>
> >
> > Some inode related improvements, to use an xarray to track open inodes per
> > root instead of a red black tree, reduce lock contention and use less memory
> > per btrfs inode, so now we can fit 4 inodes per 4K page instead of 3.
> > More details in the the change logs.
>
> Outstanding! You managed to reduce the size by 48 bytes, on my config
> from 1080 to 1032. Which unfortunately means it's still 3 inodes in a
> page. The config is maximal regarding the conditional features that
> affect size of struct inode. All of them could be enabled on distro
> kernels (checked on openSUSE):
>
> Ifdefs in include/linux/fs.h struct inode:
>
> #ifdef CONFIG_FS_POSIX_ACL
> #ifdef CONFIG_SECURITY
> #ifdef CONFIG_CGROUP_WRITEBACK
> #ifdef CONFIG_FSNOTIFY
> #ifdef CONFIG_FS_ENCRYPTION
> #ifdef CONFIG_FS_VERITY
>
> There's also #ifdef __NEED_I_SIZE_ORDERED but that's for 32bit only.
>
> This is the pahole diff summary before and after the patchset on
> for-next with my reference release config:
>
>  -       /* size: 1080, cachelines: 17, members: 39 */
>  -       /* sum members: 1075, holes: 2, sum holes: 5 */
>  -       /* forced alignments: 2 */
>  -       /* last cacheline: 56 bytes */
>  +       /* size: 1032, cachelines: 17, members: 36 */
>  +       /* sum members: 1026, holes: 2, sum holes: 6 */
>  +       /* forced alignments: 1 */
>  +       /* last cacheline: 8 bytes */
>
> The sum is still over 1024 so we'll need to find more tricks to reduce
> the space.  There are 2 holes, one is 4 bytes (after i_otime_nsec) so
> there's still some potential.

I'm seeing a reduction down to 1016 bytes because I don't have
CONFIG_FS_ENCRYPTION and CONFIG_FS_VERITY set.
It's a very old kernel config I keep reusing for several years, so
that explains it.