public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: fdmanana@kernel.org
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 7/8] btrfs: use a dedicated data structure for chunk maps
Date: Tue, 21 Nov 2023 19:23:14 +0100	[thread overview]
Message-ID: <20231121182314.GU11264@twin.jikos.cz> (raw)
In-Reply-To: <777320fd09dfc68a89180723bf5d7368dab06299.1700573314.git.fdmanana@suse.com>

On Tue, Nov 21, 2023 at 01:38:38PM +0000, fdmanana@kernel.org wrote:
>  extern const struct btrfs_raid_attr btrfs_raid_array[BTRFS_NR_RAID_TYPES];
>  
> -struct map_lookup {
> +struct btrfs_chunk_map {
> +	struct rb_node rb_node;
> +	refcount_t refs;
> +	u64 start;
> +	u64 chunk_len;
> +	u64 stripe_size;
>  	u64 type;
>  	int io_align;
>  	int io_width;
>  	int num_stripes;
>  	int sub_stripes;
> -	int verified_stripes; /* For mount time dev extent verification */
> +	/* For mount time dev extent verification. */
> +	int verified_stripes;
>  	struct btrfs_io_stripe stripes[];
>  };

This results in two 4 byte holes:

struct btrfs_chunk_map {
        struct rb_node             rb_node __attribute__((__aligned__(8))); /*     0    24 */
        refcount_t                 refs;                 /*    24     4 */

        /* XXX 4 bytes hole, try to pack */

        u64                        start;                /*    32     8 */
        u64                        chunk_len;            /*    40     8 */
        u64                        stripe_size;          /*    48     8 */
        u64                        type;                 /*    56     8 */
        /* --- cacheline 1 boundary (64 bytes) --- */
        int                        io_align;             /*    64     4 */
        int                        io_width;             /*    68     4 */
        int                        num_stripes;          /*    72     4 */
        int                        sub_stripes;          /*    76     4 */
        int                        verified_stripes;     /*    80     4 */

        /* XXX 4 bytes hole, try to pack */

        struct btrfs_io_stripe     stripes[];            /*    88     0 */

        /* size: 88, cachelines: 2, members: 12 */
        /* sum members: 80, holes: 2, sum holes: 8 */
        /* forced alignments: 1 */
        /* last cacheline: 24 bytes */
} __attribute__((__aligned__(8)));

I could move verify_stripes after refs or move refs to start of the
second cacheline between type and io_align. I suspect some cache
bouncing could happen with refcount updates and tree traversal but it's
a speculation and I don't think the effects would be measurable.

  parent reply	other threads:[~2023-11-21 18:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-21 13:38 [PATCH 0/8] btrfs: add a btrfs_chunk_map structure and preparatory cleanups fdmanana
2023-11-21 13:38 ` [PATCH 1/8] btrfs: fix off-by-one when checking chunk map includes logical address fdmanana
2023-11-21 13:38 ` [PATCH 2/8] btrfs: make error messages more clear when getting a chunk map fdmanana
2023-11-21 13:38 ` [PATCH 3/8] btrfs: mark sanity checks when getting chunk map as unlikely fdmanana
2023-11-21 13:38 ` [PATCH 4/8] btrfs: split assert into two different asserts when removing block group fdmanana
2023-11-21 13:38 ` [PATCH 5/8] btrfs: unexport extent_map_block_end() fdmanana
2023-11-21 13:38 ` [PATCH 6/8] btrfs: use btrfs_next_item() at scrub.c:find_first_extent_item() fdmanana
2023-11-21 13:38 ` [PATCH 7/8] btrfs: use a dedicated data structure for chunk maps fdmanana
2023-11-21 15:19   ` David Sterba
2023-11-21 16:50     ` Filipe Manana
2023-11-21 18:08       ` David Sterba
2023-11-21 18:23   ` David Sterba [this message]
2023-11-22 11:32     ` Filipe Manana
2023-11-22 14:16       ` David Sterba
2023-11-21 21:25   ` kernel test robot
2023-11-21 13:38 ` [PATCH 8/8] btrfs: remove stripe size local variable from insert_dev_extents() fdmanana
2023-11-21 14:12 ` [PATCH 0/8] btrfs: add a btrfs_chunk_map structure and preparatory cleanups Josef Bacik
2023-11-21 21:03 ` 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=20231121182314.GU11264@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=fdmanana@kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    /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