public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Timofey Titovets <nefelim4ag@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 4/4] [RESEND] Btrfs: reduce size of struct btrfs_inode
Date: Thu, 26 Apr 2018 15:42:06 +0200	[thread overview]
Message-ID: <20180426134206.GV21272@twin.jikos.cz> (raw)
In-Reply-To: <20180424233717.31283-5-nefelim4ag@gmail.com>

On Wed, Apr 25, 2018 at 02:37:17AM +0300, Timofey Titovets wrote:
> Currently btrfs_inode have size equal 1136 bytes. (On x86_64).
> 
> struct btrfs_inode store several vars releated to compression code,
> all states use 1 or 2 bits.
> 
> Lets declare bitfields for compression releated vars, to reduce
> sizeof btrfs_inode to 1128 bytes.

Unfortunatelly, this has no big effect. The inodes are allocated from a
slab page, that's 4k and there are at most 3 inodes there. Snippet from
/proc/slabinfo:

# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
btrfs_inode       256043 278943   1096    3    1

The size on my box is 1096 as it's 4.14, but this should not matter to
demonstrate the idea.

objperslab is 3 here, ie. there are 3 btrfs_inode in the page, and
there's 4096 - 3 * 1096 = 808 of slack space. In order to pack 4 inodes
per page, we'd have to squeeze the inode size to 1024 bytes. I've looked
into that and did not see enough members to remove or substitute. IIRC
there were like 24-32 bytes possible to shave, but that was it.

Once we'd get to 1024, adding anything new to btrfs_inode would be quite
difficult and as it goes, there's always something to add to the inode.

So I'd take a different approach, to regroup items and decide by
cacheline access patterns what to put together and what to separate.

The maximum size of inode before going to 2 objects per page is 1365, so
there's enough space for cacheline alignments.

  reply	other threads:[~2018-04-26 13:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-24 23:37 [PATCH 0/4] [RESEND] Btrfs: just bunch of patches to ioctl.c Timofey Titovets
2018-04-24 23:37 ` [PATCH 1/4] [RESEND] Btrfs: btrfs_dedupe_file_range() ioctl, remove 16MiB restriction Timofey Titovets
2018-04-26 14:03   ` David Sterba
2018-04-28  9:35     ` Timofey Titovets
2018-04-24 23:37 ` [PATCH 2/4] [RESEND] Btrfs: make should_defrag_range() understood compressed extents Timofey Titovets
2018-04-24 23:37 ` [PATCH 3/4] [RESEND] Btrfs: allow btrfs_defrag_file() uncompress files on defragmentation Timofey Titovets
2018-04-24 23:37 ` [PATCH 4/4] [RESEND] Btrfs: reduce size of struct btrfs_inode Timofey Titovets
2018-04-26 13:42   ` David Sterba [this message]
2018-04-28 10:01     ` Timofey Titovets
2018-05-01 15:39       ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180426134206.GV21272@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nefelim4ag@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox