From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>,
Nikolay Borisov <nborisov@suse.com>,
David Sterba <dsterba@suse.com>
Subject: [PATCH v3 05/15] btrfs: extent_io: calculate inline extent buffer page size based on page size
Date: Wed, 2 Dec 2020 14:48:01 +0800 [thread overview]
Message-ID: <20201202064811.100688-6-wqu@suse.com> (raw)
In-Reply-To: <20201202064811.100688-1-wqu@suse.com>
Btrfs only support 64K as max node size, thus for 4K page system, we
would have at most 16 pages for one extent buffer.
For a system using 64K page size, we would really have just one
single page.
While we always use 16 pages for extent_buffer::pages[], this means for
systems using 64K pages, we are wasting memory for the 15 pages which
will never be utilized.
So this patch will change how the extent_buffer::pages[] array size is
calclulated, now it will be calculated using
BTRFS_MAX_METADATA_BLOCKSIZE and PAGE_SIZE.
For systems using 4K page size, it will stay 16 pages.
For systems using 64K page size, it will be just 1 page.
Since we're here, also move the definition of
BTRFS_MAX_METADATA_BLOCKSIZE to btrfs_tree.h, to avoid circle including
of ctree.h.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
---
fs/btrfs/ctree.h | 6 ------
fs/btrfs/extent_io.c | 7 +------
fs/btrfs/extent_io.h | 4 ++--
include/uapi/linux/btrfs_tree.h | 4 ++++
4 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 112c9a2ae47b..c5ef29078954 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -67,12 +67,6 @@ struct btrfs_ref;
#define BTRFS_OLDEST_GENERATION 0ULL
-/*
- * the max metadata block size. This limit is somewhat artificial,
- * but the memmove costs go through the roof for larger blocks.
- */
-#define BTRFS_MAX_METADATA_BLOCKSIZE 65536
-
/*
* we can actually store much bigger names, but lets not confuse the rest
* of linux
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 4b72c824064c..2bab66b42395 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -5053,12 +5053,7 @@ __alloc_extent_buffer(struct btrfs_fs_info *fs_info, u64 start,
atomic_set(&eb->refs, 1);
atomic_set(&eb->io_pages, 0);
- /*
- * Sanity checks, currently the maximum is 64k covered by 16x 4k pages
- */
- BUILD_BUG_ON(BTRFS_MAX_METADATA_BLOCKSIZE
- > MAX_INLINE_EXTENT_BUFFER_SIZE);
- BUG_ON(len > MAX_INLINE_EXTENT_BUFFER_SIZE);
+ ASSERT(len <= BTRFS_MAX_METADATA_BLOCKSIZE);
return eb;
}
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index db95468801c7..02b4786478b6 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -6,6 +6,7 @@
#include <linux/rbtree.h>
#include <linux/refcount.h>
#include <linux/fiemap.h>
+#include <linux/btrfs_tree.h>
#include "ulist.h"
/*
@@ -74,8 +75,7 @@ typedef blk_status_t (submit_bio_hook_t)(struct inode *inode, struct bio *bio,
typedef blk_status_t (extent_submit_bio_start_t)(struct inode *inode,
struct bio *bio, u64 opt_file_offset);
-#define INLINE_EXTENT_BUFFER_PAGES 16
-#define MAX_INLINE_EXTENT_BUFFER_SIZE (INLINE_EXTENT_BUFFER_PAGES * PAGE_SIZE)
+#define INLINE_EXTENT_BUFFER_PAGES (BTRFS_MAX_METADATA_BLOCKSIZE / PAGE_SIZE)
struct extent_buffer {
u64 start;
unsigned long len;
diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
index 6b885982ece6..44e22f935b8c 100644
--- a/include/uapi/linux/btrfs_tree.h
+++ b/include/uapi/linux/btrfs_tree.h
@@ -4,6 +4,7 @@
#include <linux/btrfs.h>
#include <linux/types.h>
+#include <linux/sizes.h>
#ifdef __KERNEL__
#include <linux/stddef.h>
#else
@@ -990,4 +991,7 @@ struct btrfs_qgroup_limit_item {
__le64 rsv_excl;
} __attribute__ ((__packed__));
+/* Maximum metadata block size (nodesize) */
+#define BTRFS_MAX_METADATA_BLOCKSIZE SZ_64K
+
#endif /* _BTRFS_CTREE_H_ */
--
2.29.2
next prev parent reply other threads:[~2020-12-02 6:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 6:47 [PATCH v3 00/15] btrfs: preparation patches for subpage support Qu Wenruo
2020-12-02 6:47 ` [PATCH v3 01/15] btrfs: rename bio_offset of extent_submit_bio_start_t to opt_file_offset Qu Wenruo
2020-12-02 8:12 ` Christoph Hellwig
2020-12-03 18:45 ` David Sterba
2020-12-02 6:47 ` [PATCH v3 02/15] btrfs: pass bio_offset to check_data_csum() directly Qu Wenruo
2020-12-02 6:47 ` [PATCH v3 03/15] btrfs: inode: make btrfs_verify_data_csum() follow sector size Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 04/15] btrfs: extent_io: extract the btree page submission code into its own helper function Qu Wenruo
2020-12-02 6:48 ` Qu Wenruo [this message]
2020-12-02 6:48 ` [PATCH v3 06/15] btrfs: extent_io: don't allow tree block to cross page boundary for subpage support Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 07/15] btrfs: extent_io: update num_extent_pages() to support subpage sized extent buffer Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 08/15] btrfs: handle sectorsize < PAGE_SIZE case for extent buffer accessors Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 09/15] btrfs: file-item: remove the btrfs_find_ordered_sum() call in btrfs_lookup_bio_sums() Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 10/15] btrfs: file-item: refactor btrfs_lookup_bio_sums() to handle out-of-order bvecs Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 11/15] btrfs: scrub: reduce the width for extent_len/stripe_len from 64 bits to 32 bits Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 12/15] btrfs: scrub: always allocate one full page for one sector for RAID56 Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 13/15] btrfs: scrub: support subpage tree block scrub Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 14/15] btrfs: scrub: support subpage data scrub Qu Wenruo
2020-12-02 6:48 ` [PATCH v3 15/15] btrfs: scrub: allow scrub to work with subpage sectorsize Qu Wenruo
2020-12-04 15:18 ` [PATCH v3 00/15] btrfs: preparation patches for subpage support 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=20201202064811.100688-6-wqu@suse.com \
--to=wqu@suse.com \
--cc=dsterba@suse.com \
--cc=johannes.thumshirn@wdc.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.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