All of lore.kernel.org
 help / color / mirror / Atom feed
From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 17/18] btrfs: send: update size of roots array for backref cache entries
Date: Thu, 19 Jan 2023 19:39:29 +0000	[thread overview]
Message-ID: <5c3179983276d6fe5096023e5b30e7b6564c53a6.1674157020.git.fdmanana@suse.com> (raw)
In-Reply-To: <cover.1674157020.git.fdmanana@suse.com>

From: Filipe Manana <fdmanana@suse.com>

Currently we limit the size of the roots array, for backref cache entries,
to 12 elements. This is because that number is enough for most cases and
to make the backref cache entry size to be exactly 128 bytes, so that
memory is allocated from the kmalloc-128 slab and no space is wasted.

However recent changes in the series refactored the backref cache to be
more generic and allow it to be reused for other purposes, which resulted
in increasing the size of the embedded structure btrfs_lru_cache_entry in
order to allow for supporting inode numbers as keys on 32 bits system and
allow multiple generations per key. This resulted in increasing the size
of struct backref_cache_entry from 128 bytes to 152 bytes. Since the cache
entries are allocated with kmalloc(), it means we end up using the slab
kmalloc-192, so we end up wasting 40 bytes of memory. So bump the size of
the roots array from 12 elements to 17 elements, so we end up using 192
bytes for each backref cache entry.

This patch is part of a larger patchset and the changelog of the last
patch in the series contains a sample performance test and results.
The patches that comprise the patchset are the following:

  btrfs: send: directly return from did_overwrite_ref() and simplify it
  btrfs: send: avoid unnecessary generation search at did_overwrite_ref()
  btrfs: send: directly return from will_overwrite_ref() and simplify it
  btrfs: send: avoid extra b+tree searches when checking reference overrides
  btrfs: send: remove send_progress argument from can_rmdir()
  btrfs: send: avoid duplicated orphan dir allocation and initialization
  btrfs: send: avoid unnecessary orphan dir rbtree search at can_rmdir()
  btrfs: send: reduce searches on parent root when checking if dir can be removed
  btrfs: send: iterate waiting dir move rbtree only once when processing refs
  btrfs: send: initialize all the red black trees earlier
  btrfs: send: genericize the backref cache to allow it to be reused
  btrfs: adapt lru cache to allow for 64 bits keys on 32 bits systems
  btrfs: send: cache information about created directories
  btrfs: allow a generation number to be associated with lru cache entries
  btrfs: add an api to delete a specific entry from the lru cache
  btrfs: send: use the lru cache to implement the name cache
  btrfs: send: update size of roots array for backref cache entries
  btrfs: send: cache utimes operations for directories if possible

Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
 fs/btrfs/send.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 7d327d977fa0..ae2d462f647e 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -84,19 +84,20 @@ struct clone_root {
 #define SEND_MAX_NAME_CACHE_SIZE 256
 
 /*
- * Limit the root_ids array of struct backref_cache_entry to 12 elements.
- * This makes the size of a cache entry to be exactly 128 bytes on x86_64.
+ * Limit the root_ids array of struct backref_cache_entry to 17 elements.
+ * This makes the size of a cache entry to be exactly 192 bytes on x86_64, which
+ * can be satisfied from the kmalloc-192 slab, without wasting any space.
  * The most common case is to have a single root for cloning, which corresponds
- * to the send root. Having the user specify more than 11 clone roots is not
+ * to the send root. Having the user specify more than 16 clone roots is not
  * common, and in such rare cases we simply don't use caching if the number of
- * cloning roots that lead down to a leaf is more than 12.
+ * cloning roots that lead down to a leaf is more than 17.
  */
-#define SEND_MAX_BACKREF_CACHE_ROOTS 12
+#define SEND_MAX_BACKREF_CACHE_ROOTS 17
 
 /*
  * Max number of entries in the cache.
- * With SEND_MAX_BACKREF_CACHE_ROOTS as 12, the size in bytes, excluding
- * maple tree's internal nodes, is 16K.
+ * With SEND_MAX_BACKREF_CACHE_ROOTS as 17, the size in bytes, excluding
+ * maple tree's internal nodes, is 24K.
  */
 #define SEND_MAX_BACKREF_CACHE_SIZE 128
 
-- 
2.35.1


  parent reply	other threads:[~2023-01-20  5:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-11 11:36 [PATCH 00/19] btrfs: some optimizations for send fdmanana
2023-01-11 11:36 ` [PATCH 01/19] btrfs: send: directly return from did_overwrite_ref() and simplify it fdmanana
2023-01-11 11:36 ` [PATCH 02/19] btrfs: send: avoid unnecessary generation search at did_overwrite_ref() fdmanana
2023-01-11 11:36 ` [PATCH 03/19] btrfs: send: directly return from will_overwrite_ref() and simplify it fdmanana
2023-01-11 11:36 ` [PATCH 04/19] btrfs: send: avoid extra b+tree searches when checking reference overrides fdmanana
2023-01-11 11:36 ` [PATCH 05/19] btrfs: send: remove send_progress argument from can_rmdir() fdmanana
2023-01-11 11:36 ` [PATCH 06/19] btrfs: send: avoid duplicated orphan dir allocation and initialization fdmanana
2023-01-11 11:36 ` [PATCH 07/19] btrfs: send: avoid unnecessary orphan dir rbtree search at can_rmdir() fdmanana
2023-01-11 11:36 ` [PATCH 08/19] btrfs: send: reduce searches on parent root when checking if dir can be removed fdmanana
2023-01-11 11:36 ` [PATCH 09/19] btrfs: send: iterate waiting dir move rbtree only once when processing refs fdmanana
2023-01-11 11:36 ` [PATCH 10/19] btrfs: send: use MT_FLAGS_LOCK_EXTERN for the backref cache maple tree fdmanana
2023-01-11 11:36 ` [PATCH 11/19] btrfs: send: initialize all the red black trees earlier fdmanana
2023-01-11 11:36 ` [PATCH 12/19] btrfs: send: genericize the backref cache to allow it to be reused fdmanana
2023-01-11 11:36 ` [PATCH 13/19] btrfs: adapt lru cache to allow for 64 bits keys on 32 bits systems fdmanana
2023-01-11 11:36 ` [PATCH 14/19] btrfs: send: cache information about created directories fdmanana
2023-01-11 11:36 ` [PATCH 15/19] btrfs: allow a generation number to be associated with lru cache entries fdmanana
2023-01-11 11:36 ` [PATCH 16/19] btrfs: add an api to delete a specific entry from the lru cache fdmanana
2023-01-11 11:36 ` [PATCH 17/19] btrfs: send: use the lru cache to implement the name cache fdmanana
2023-01-11 11:36 ` [PATCH 18/19] btrfs: send: update size of roots array for backref cache entries fdmanana
2023-01-11 11:36 ` [PATCH 19/19] btrfs: send: cache utimes operations for directories if possible fdmanana
2023-01-19 19:39 ` [PATCH v2 00/18] btrfs: some optimizations for send fdmanana
2023-01-19 19:39   ` [PATCH v2 01/18] btrfs: send: directly return from did_overwrite_ref() and simplify it fdmanana
2023-01-19 19:39   ` [PATCH v2 02/18] btrfs: send: avoid unnecessary generation search at did_overwrite_ref() fdmanana
2023-01-19 19:39   ` [PATCH v2 03/18] btrfs: send: directly return from will_overwrite_ref() and simplify it fdmanana
2023-01-19 19:39   ` [PATCH v2 04/18] btrfs: send: avoid extra b+tree searches when checking reference overrides fdmanana
2023-01-19 19:39   ` [PATCH v2 05/18] btrfs: send: remove send_progress argument from can_rmdir() fdmanana
2023-01-19 19:39   ` [PATCH v2 06/18] btrfs: send: avoid duplicated orphan dir allocation and initialization fdmanana
2023-01-19 19:39   ` [PATCH v2 07/18] btrfs: send: avoid unnecessary orphan dir rbtree search at can_rmdir() fdmanana
2023-01-19 19:39   ` [PATCH v2 08/18] btrfs: send: reduce searches on parent root when checking if dir can be removed fdmanana
2023-01-19 19:39   ` [PATCH v2 09/18] btrfs: send: iterate waiting dir move rbtree only once when processing refs fdmanana
2023-01-19 19:39   ` [PATCH v2 10/18] btrfs: send: initialize all the red black trees earlier fdmanana
2023-01-19 19:39   ` [PATCH v2 11/18] btrfs: send: genericize the backref cache to allow it to be reused fdmanana
2023-01-19 19:39   ` [PATCH v2 12/18] btrfs: adapt lru cache to allow for 64 bits keys on 32 bits systems fdmanana
2023-01-19 19:39   ` [PATCH v2 13/18] btrfs: send: cache information about created directories fdmanana
2023-01-19 19:39   ` [PATCH v2 14/18] btrfs: allow a generation number to be associated with lru cache entries fdmanana
2023-01-19 19:39   ` [PATCH v2 15/18] btrfs: add an api to delete a specific entry from the lru cache fdmanana
2023-01-19 19:39   ` [PATCH v2 16/18] btrfs: send: use the lru cache to implement the name cache fdmanana
2023-01-19 19:39   ` fdmanana [this message]
2023-01-19 19:39   ` [PATCH v2 18/18] btrfs: send: cache utimes operations for directories if possible fdmanana
2023-01-20 18:45   ` [PATCH v2 00/18] btrfs: some optimizations for send 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=5c3179983276d6fe5096023e5b30e7b6564c53a6.1674157020.git.fdmanana@suse.com \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.