linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v3 7/7] btrfs: use larger blocksize for data extent scrub
Date: Mon,  8 Aug 2022 13:45:43 +0800	[thread overview]
Message-ID: <5eeff66dec955d3168ef2a4abb120a063d55e78c.1659936510.git.wqu@suse.com> (raw)
In-Reply-To: <cover.1659936510.git.wqu@suse.com>

[PROBLEM]
The existing scrub code for data extents always limit the blocksize to
sectorsize.

This causes quite some extra scrub_block being allocated:
(there is a data extent at logical bytenr 298844160, length 64KiB)

 alloc_scrub_block: new block: logical=298844160 physical=298844160 mirror=1
 alloc_scrub_block: new block: logical=298848256 physical=298848256 mirror=1
 alloc_scrub_block: new block: logical=298852352 physical=298852352 mirror=1
 alloc_scrub_block: new block: logical=298856448 physical=298856448 mirror=1
 alloc_scrub_block: new block: logical=298860544 physical=298860544 mirror=1
 alloc_scrub_block: new block: logical=298864640 physical=298864640 mirror=1
 alloc_scrub_block: new block: logical=298868736 physical=298868736 mirror=1
 alloc_scrub_block: new block: logical=298872832 physical=298872832 mirror=1
 alloc_scrub_block: new block: logical=298876928 physical=298876928 mirror=1
 alloc_scrub_block: new block: logical=298881024 physical=298881024 mirror=1
 alloc_scrub_block: new block: logical=298885120 physical=298885120 mirror=1
 alloc_scrub_block: new block: logical=298889216 physical=298889216 mirror=1
 alloc_scrub_block: new block: logical=298893312 physical=298893312 mirror=1
 alloc_scrub_block: new block: logical=298897408 physical=298897408 mirror=1
 alloc_scrub_block: new block: logical=298901504 physical=298901504 mirror=1
 alloc_scrub_block: new block: logical=298905600 physical=298905600 mirror=1
 ...
 scrub_block_put: free block: logical=298844160 physical=298844160 len=4096 mirror=1
 scrub_block_put: free block: logical=298848256 physical=298848256 len=4096 mirror=1
 scrub_block_put: free block: logical=298852352 physical=298852352 len=4096 mirror=1
 scrub_block_put: free block: logical=298856448 physical=298856448 len=4096 mirror=1
 scrub_block_put: free block: logical=298860544 physical=298860544 len=4096 mirror=1
 scrub_block_put: free block: logical=298864640 physical=298864640 len=4096 mirror=1
 scrub_block_put: free block: logical=298868736 physical=298868736 len=4096 mirror=1
 scrub_block_put: free block: logical=298872832 physical=298872832 len=4096 mirror=1
 scrub_block_put: free block: logical=298876928 physical=298876928 len=4096 mirror=1
 scrub_block_put: free block: logical=298881024 physical=298881024 len=4096 mirror=1
 scrub_block_put: free block: logical=298885120 physical=298885120 len=4096 mirror=1
 scrub_block_put: free block: logical=298889216 physical=298889216 len=4096 mirror=1
 scrub_block_put: free block: logical=298893312 physical=298893312 len=4096 mirror=1
 scrub_block_put: free block: logical=298897408 physical=298897408 len=4096 mirror=1
 scrub_block_put: free block: logical=298901504 physical=298901504 len=4096 mirror=1
 scrub_block_put: free block: logical=298905600 physical=298905600 len=4096 mirror=1

This behavior will waste a lot of memory, especially after we have move
quite some members from scrub_sector to scrub_block.

[FIX]
To reduce the allocation of scrub_block, and reduce memory usage, this
patch will use BTRFS_STRIPE_LEN instead of sectorsize as the blocksize
to scrub data extents.

This results only one scrub_block to be allocated for above data extent:
 alloc_scrub_block: new block: logical=298844160 physical=298844160 mirror=1
 scrub_block_put: free block: logical=298844160 physical=298844160 len=65536 mirror=1

This would greatly reduce the memory usage (even it's just transient)
for larger data extents scrub.

For above example, the memory usage would be:

Old: num_sectors * (sizeof(scrub_block) + sizeof(scrub_sector))
     16          * (408                  + 96) = 8065

New: sizeof(scrub_block) + num_sectors * sizeof(scrub_sector)
     408                 + 16          * 96 = 1944

A good reduction of 75.9%.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/scrub.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 6c5be7cf00d0..ff251b7fbd47 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -2671,11 +2671,17 @@ static int scrub_extent(struct scrub_ctx *sctx, struct map_lookup *map,
 	u8 csum[BTRFS_CSUM_SIZE];
 	u32 blocksize;
 
+	/*
+	 * Block size determines how many scrub_block will be allocated.
+	 * Here we use BTRFS_STRIPE_LEN (64KiB) as default limit, so we
+	 * won't allocate too many scrub_block, while still won't cause
+	 * too large bios for large extents.
+	 */
 	if (flags & BTRFS_EXTENT_FLAG_DATA) {
 		if (map->type & BTRFS_BLOCK_GROUP_RAID56_MASK)
 			blocksize = map->stripe_len;
 		else
-			blocksize = sctx->fs_info->sectorsize;
+			blocksize = BTRFS_STRIPE_LEN;
 		spin_lock(&sctx->stat_lock);
 		sctx->stat.data_extents_scrubbed++;
 		sctx->stat.data_bytes_scrubbed += len;
-- 
2.37.0


      parent reply	other threads:[~2022-08-08  5:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-08  5:45 [PATCH v3 0/7] btrfs: scrub: changes to reduce memory usage for both regular and subpage sectorsize Qu Wenruo
2022-08-08  5:45 ` [PATCH v3 1/7] btrfs: scrub: use pointer array to replace @sblocks_for_recheck Qu Wenruo
2022-08-08  5:45 ` [PATCH v3 2/7] btrfs: extract the initialization of scrub_block into a helper function Qu Wenruo
2022-08-08  5:45 ` [PATCH v3 3/7] btrfs: extract the allocation and initialization of scrub_sector into a helper Qu Wenruo
2022-08-08  5:45 ` [PATCH v3 4/7] btrfs: scrub: introduce scrub_block::pages for more efficient memory usage for subpage Qu Wenruo
2022-08-08  5:45 ` [PATCH v3 5/7] btrfs: scrub: remove scrub_sector::page and use scrub_block::pages instead Qu Wenruo
2022-08-08  5:45 ` [PATCH v3 6/7] btrfs: scrub: move logical/physical/dev/mirror_num from scrub_sector to scrub_block Qu Wenruo
2022-08-08  5:45 ` Qu Wenruo [this message]

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=5eeff66dec955d3168ef2a4abb120a063d55e78c.1659936510.git.wqu@suse.com \
    --to=wqu@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;
as well as URLs for NNTP newsgroup(s).