All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/6] btrfs: preparation patches for the incoming metadata folio conversion
Date: Wed, 12 Jul 2023 14:37:40 +0800	[thread overview]
Message-ID: <cover.1689143654.git.wqu@suse.com> (raw)

[CHANGELOG]
v2:
- Define write_extent_buffer_fsid/chunk_tree_uuid() as inline helpers

[BACKGROUND]

Recently I'm checking on the feasibility on converting metadata handling
to go a folio based solution.

The best part of using a single folio for metadata is, we can get rid of
the complexity of cross-page handling, everything would be just a single
memory operation on a continuous memory range.

[PITFALLS]

One of the biggest problem for metadata folio conversion is, we still
need the current page based solution (or folios with order 0) as a
fallback solution when we can not get a high order folio.

In that case, there would be a hell to handle the four different
combinations (folio/folio, folio/page, page/folio, page/page) for extent
buffer helpers involving two extent buffers.

Although there are some new ideas on how to handle metadata memory (e.g.
go full vmallocated memory), reducing the open-coded memory handling for
metadata should always be a good start point.

[OBJECTIVE]

So this patchset is the preparation to reduce direct page operations for
metadata.

The patchset would do this mostly by concentrating the operations to use
the common helper, write_extent_buffer() and read_extent_buffer().

For bitmap operations it's much complex, thus this patchset refactor it
completely to go a 3 part solution:

- Handle the first byte
- Handle the byte aligned ranges
- Handle the last byte

This needs more complex testing (which I failed several times during
development) to prevent regression.

Finally there is only one function which can not be properly migrated,
memmove_extent_buffer(), which has to use memmove() calls, thus must go
per-page mapping handling.

Thankfully if we go folio in the end, the folio based handling would
just be a single memmove(), thus it won't be too much burden.


Qu Wenruo (6):
  btrfs: tests: enhance extent buffer bitmap tests
  btrfs: refactor extent buffer bitmaps operations
  btrfs: use write_extent_buffer() to implement
    write_extent_buffer_*id()
  btrfs: refactor memcpy_extent_buffer()
  btrfs: refactor copy_extent_buffer_full()
  btrfs: call copy_extent_buffer_full() inside
    btrfs_clone_extent_buffer()

 fs/btrfs/extent_io.c             | 224 +++++++++++++------------------
 fs/btrfs/extent_io.h             |  19 ++-
 fs/btrfs/tests/extent-io-tests.c | 161 ++++++++++++++--------
 3 files changed, 215 insertions(+), 189 deletions(-)

-- 
2.41.0


             reply	other threads:[~2023-07-12  6:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-12  6:37 Qu Wenruo [this message]
2023-07-12  6:37 ` [PATCH v2 1/6] btrfs: tests: enhance extent buffer bitmap tests Qu Wenruo
2023-07-12  6:37 ` [PATCH v2 2/6] btrfs: refactor extent buffer bitmaps operations Qu Wenruo
2023-07-13 11:53   ` David Sterba
2023-07-12  6:37 ` [PATCH v2 3/6] btrfs: use write_extent_buffer() to implement write_extent_buffer_*id() Qu Wenruo
2023-07-12  6:37 ` [PATCH v2 4/6] btrfs: refactor memcpy_extent_buffer() Qu Wenruo
2023-07-13 11:51   ` David Sterba
2023-07-12  6:37 ` [PATCH v2 5/6] btrfs: refactor copy_extent_buffer_full() Qu Wenruo
2023-07-12  6:37 ` [PATCH v2 6/6] btrfs: call copy_extent_buffer_full() inside btrfs_clone_extent_buffer() Qu Wenruo
2023-07-13 11:55   ` David Sterba
2023-07-12  6:44 ` [PATCH v2 0/6] btrfs: preparation patches for the incoming metadata folio conversion Sweet Tea Dorminy
2023-07-12 16:41 ` Christoph Hellwig
2023-07-12 23:58   ` Qu Wenruo
2023-07-13 11:16     ` Christoph Hellwig
2023-07-13 11:26     ` David Sterba
2023-07-13 11:41       ` Qu Wenruo
2023-07-13 11:49         ` David Sterba
2023-07-13 12:09 ` David Sterba
2023-07-13 16:39   ` David Sterba
2023-07-13 21:30     ` Qu Wenruo
2023-07-13 22:03       ` David Sterba
2023-07-14  0:09         ` Qu Wenruo
2023-07-14  0:26           ` David Sterba
2023-07-14  1:58             ` Qu Wenruo
2023-07-14 10:03               ` David Sterba
2023-07-14 10:32                 ` Qu Wenruo
2023-07-14 10:41                   ` David Sterba
2023-07-15  0:39                     ` Qu Wenruo
2023-07-15  1:02                       ` Qu Wenruo

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=cover.1689143654.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 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.