From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] btrfs: migrate IO path to folios
Date: Fri, 8 Dec 2023 20:24:20 +1030 [thread overview]
Message-ID: <cover.1702028578.git.wqu@suse.com> (raw)
One critical problem I hit the most during my initial higher order
folios tests are, incorrect access to the pages which conflicts with the
page flag policy.
Since folio flags are only set to certain pages according to their
policies (PF_ANY, PF_HEAD, PF_ONLY_HEAD, PF_NO_TAIL, PF_NO_COMPOUND and
the most weird on PF_SECOND), setting page flags violating the policy
would immedate lead to VM_BUG_ON().
Thus no matter if we go compound page or folio, we can not go the
page-by-page iteration helpers that easily.
One of the hot spots which can lead to VM_BUG_ON()s are the endio
helpers.
So this patch would:
- Make metadata set/get helpers to utilize folio interfaces
- Make subpage code to accept folios directly
This is to avoid btrfs_page_*() helpers to accept page pointers, which
is another hot spot which uses page pointer a lot.
- Migrate btrfs bio endio functions to utilize bio_for_each_folio_all()
This completely removes the ability to direct access page pointers.
Although we still need some extra folio_page(folio, 0) calls to keep
compatible with existing helpers.
And since we're here, also fix the choas of btrfs endio functions'
naming scheme, now it would always be:
end_bbio_<target>_(read|write)
The <target> can be:
- data
For non-compressed and non-encoeded operations
- meta
- compressed
For compressed IO and encoded IO.
And since compressed IO path is utilizing unmapped pages (pages
without an address_space), thus they don't touch the page flags.
This makes compressed IO path a very good test bed for the initial
introduction of higher order folio.
Qu Wenruo (3):
btrfs: migrate get_eb_page_index() and get_eb_offset_in_page() to
folios
btrfs: migrate subpage code to folio interfaces
btrfs: migrate various btrfs end io functions to folios
fs/btrfs/accessors.c | 80 ++++----
fs/btrfs/compression.c | 15 +-
fs/btrfs/ctree.c | 13 +-
fs/btrfs/defrag.c | 3 +-
fs/btrfs/disk-io.c | 4 +-
fs/btrfs/extent_io.c | 361 +++++++++++++++++++-----------------
fs/btrfs/extent_io.h | 40 ++--
fs/btrfs/file.c | 13 +-
fs/btrfs/free-space-cache.c | 4 +-
fs/btrfs/inode.c | 34 ++--
fs/btrfs/ordered-data.c | 5 +-
fs/btrfs/reflink.c | 6 +-
fs/btrfs/relocation.c | 5 +-
fs/btrfs/subpage.c | 304 +++++++++++++++---------------
fs/btrfs/subpage.h | 74 ++++----
15 files changed, 499 insertions(+), 462 deletions(-)
--
2.43.0
next reply other threads:[~2023-12-08 9:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 9:54 Qu Wenruo [this message]
2023-12-08 9:54 ` [PATCH 1/3] btrfs: migrate get_eb_page_index() and get_eb_offset_in_page() to folios Qu Wenruo
2023-12-08 9:54 ` [PATCH 2/3] btrfs: migrate subpage code to folio interfaces Qu Wenruo
2023-12-08 9:54 ` [PATCH 3/3] btrfs: migrate various btrfs end io functions to folios 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.1702028578.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