public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 7/7] btrfs: accessors: factor out split memcpy with two sources
Date: Wed, 2 Jul 2025 11:53:37 -0700	[thread overview]
Message-ID: <20250702185337.GC2308047@zen.localdomain> (raw)
In-Reply-To: <1db66bf81b5790c6e14183a5c30a8abf6d1b1126.1751390044.git.dsterba@suse.com>

On Tue, Jul 01, 2025 at 07:23:54PM +0200, David Sterba wrote:
> The case of a reading the bytes from 2 folios needs two memcpy()s, the
> compiler does not emit calls but two inline loops.
> 
> Factoring out the code makes some improvement (stack, code) and in the
> future will provide an optimized implementation as well. (The analogical
> version with two destinations is not done as it increases stack usage
> but can be done if needed.)

Is there some fundamental reason for this, or does it just happen to be
so? Sort of interesting either way. Does it make you worry that this
stuff will regress randomly in the future?

> 
> The address of the second folio is reordered before the first memcpy,
> which leads to an optimization reusing the vmemmap_base and
> page_offset_base (implementing folio_address()).
> 
> Stack usage reduction:
> 
>   btrfs_get_32                                           -8 (32 -> 24)
>   btrfs_get_64                                           -8 (32 -> 24)
> 
> Code size reduction:
> 
>      text    data     bss     dec     hex filename
>   1454279  115665   16088 1586032  183370 pre/btrfs.ko
>   1454229  115665   16088 1585982  18333e post/btrfs.ko
> 
>   DELTA: -50
> 
> As this is the last patch in this series, here's the overall diff
> starting and including commit "btrfs: accessors: simplify folio bounds
> checks":
> 
> Stack:
> 
>   btrfs_set_16                                          -72 (88 -> 16)
>   btrfs_get_32                                          -56 (80 -> 24)
>   btrfs_set_8                                           -72 (88 -> 16)
>   btrfs_set_64                                          -64 (88 -> 24)
>   btrfs_get_8                                           -72 (80 -> 8)
>   btrfs_get_16                                          -64 (80 -> 16)
>   btrfs_set_32                                          -64 (88 -> 24)
>   btrfs_get_64                                          -56 (80 -> 24)
> 
>   NEW (48):
> 	  report_setget_bounds                           48
>   LOST/NEW DELTA:      +48
>   PRE/POST DELTA:     -472
> 
> Code:
> 
>      text    data     bss     dec     hex filename
>   1456601  115665   16088 1588354  183c82 pre/btrfs.ko
>   1454229  115665   16088 1585982  18333e post/btrfs.ko
> 
>   DELTA: -2372

Sweet!

> 
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
>  fs/btrfs/accessors.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/accessors.c b/fs/btrfs/accessors.c
> index af11f547371815..f554c4f723617f 100644
> --- a/fs/btrfs/accessors.c
> +++ b/fs/btrfs/accessors.c
> @@ -20,6 +20,15 @@ static void __cold report_setget_bounds(const struct extent_buffer *eb,
>  		   (unsigned long)ptr, eb->start, member_offset, size);
>  }
>  
> +/* Copy bytes from @src1 and @src2 to @dest. */
> +static __always_inline void memcpy_split_src(char *dest, const char *src1,
> +					     const char *src2, const size_t len1,
> +					     const size_t total)
> +{
> +	memcpy(dest, src1, len1);
> +	memcpy(dest + len1, src2, total - len1);
> +}
> +
>  /*
>   * Macro templates that define helpers to read/write extent buffer data of a
>   * given size, that are also used via ctree.h for access to item members by
> @@ -64,9 +73,9 @@ u##bits btrfs_get_##bits(const struct extent_buffer *eb,		\
>  		kaddr = folio_address(eb->folios[idx + 1]);		\
>  		lebytes[1] = *kaddr;					\
>  	} else {							\
> -		memcpy(lebytes, kaddr, part);				\
> -		kaddr = folio_address(eb->folios[idx + 1]);		\
> -		memcpy(lebytes + part, kaddr, sizeof(u##bits) - part);	\
> +		memcpy_split_src(lebytes, kaddr,			\
> +				 folio_address(eb->folios[idx + 1]),	\
> +				 part, sizeof(u##bits));		\
>  	}								\
>  	return get_unaligned_le##bits(lebytes);				\
>  }									\
> -- 
> 2.49.0
> 

  reply	other threads:[~2025-07-02 18:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-01 17:23 [PATCH 0/7] Set/get accessor speedups David Sterba
2025-07-01 17:23 ` [PATCH 1/7] btrfs: accessors: simplify folio bounds checks David Sterba
2025-07-01 17:23 ` [PATCH 2/7] btrfs: accessors: use type sizeof constants directly David Sterba
2025-07-02 17:58   ` Boris Burkov
2025-07-03 21:20     ` David Sterba
2025-07-07 14:25       ` David Sterba
2025-07-01 17:23 ` [PATCH 3/7] btrfs: accessors: inline eb bounds check and factor out the error report David Sterba
2025-07-02 18:00   ` Boris Burkov
2025-07-03 21:16     ` David Sterba
2025-07-01 17:23 ` [PATCH 4/7] btrfs: accessors: compile-time fast path for u8 David Sterba
2025-07-01 17:23 ` [PATCH 5/7] btrfs: accessors: compile-time fast path for u16 David Sterba
2025-07-01 17:23 ` [PATCH 6/7] btrfs: accessors: set target address at initialization David Sterba
2025-07-01 17:23 ` [PATCH 7/7] btrfs: accessors: factor out split memcpy with two sources David Sterba
2025-07-02 18:53   ` Boris Burkov [this message]
2025-07-03 20:57     ` David Sterba
2025-07-02 18:54 ` [PATCH 0/7] Set/get accessor speedups Boris Burkov

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=20250702185337.GC2308047@zen.localdomain \
    --to=boris@bur.io \
    --cc=dsterba@suse.com \
    --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