From: Josef Bacik <josef@toxicpanda.com>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3] btrfs: refactor alloc_extent_buffer() to allocate-then-attach method
Date: Mon, 27 Nov 2023 11:40:12 -0500 [thread overview]
Message-ID: <20231127164012.GG2366036@perftesting> (raw)
In-Reply-To: <d07c880500b59aa457fb267491664aca0e6b4b32.1700811840.git.wqu@suse.com>
On Fri, Nov 24, 2023 at 06:14:16PM +1030, Qu Wenruo wrote:
> Currently alloc_extent_buffer() utilizes find_or_create_page() to
> allocate one page a time for an extent buffer.
>
> This method has the following disadvantages:
>
> - find_or_create_page() is the legacy way of allocating new pages
> With the new folio infrastructure, find_or_create_page() is just
> redirected to filemap_get_folio().
>
> - Lacks the way to support higher order (order >= 1) folios
> As we can not yet let filemap to give us a higher order folio (yet).
>
> This patch would change the workflow by the following way:
>
> Old | new
> -----------------------------------+-------------------------------------
> | ret = btrfs_alloc_page_array();
> for (i = 0; i < num_pages; i++) { | for (i = 0; i < num_pages; i++) {
> p = find_or_create_page(); | ret = filemap_add_folio();
> /* Attach page private */ | /* Reuse page cache if needed */
> /* Reused eb if needed */ |
> | /* Attach page private and
> | reuse eb if needed */
> | }
>
> By this we split the page allocation and private attaching into two
> parts, allowing future updates to each part more easily, and migrate to
> folio interfaces (especially for possible higher order folios).
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
Sorry I just noticed the updated version of this, I sent my comments in reply to
an older version but they still hold true for this version. Thanks,
Josef
prev parent reply other threads:[~2023-11-27 16:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-24 7:44 [PATCH v3] btrfs: refactor alloc_extent_buffer() to allocate-then-attach method Qu Wenruo
2023-11-27 16:40 ` Josef Bacik [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=20231127164012.GG2366036@perftesting \
--to=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@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 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.