linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Linux Memory Management List <linux-mm@kvack.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Proper way to copy de-compressed data into a bio, in folio style?
Date: Mon, 31 Mar 2025 18:45:10 +1030	[thread overview]
Message-ID: <17517804-1c6b-4b96-a608-8c3d80e5f6dd@gmx.com> (raw)

Hi,

The seemingly easy question has some very interesting extra requirements:

1. The bio contains contig file map folios
    The folios may be large.
    So page_offset() on bv_page (using single-page bvec) is no longer
    reliable, one has to call page_pgoff() instead.

2. The data may not cover the bio range
    So we need some range comparison and skip if the data range doesn't
    cover the bio range.

3. The bio may have been advanced
    E.g. previous de-compressed range has been copied, but the remaining
    part still needs to be fulfilled.

    And we need to use the bv_page's file offset to calculate the real
    beginning of the range to copy.

The current btrfs code is doing single page bvec iteration, and handling
point 2 and 3 well.
(btrfs_decompress_buf2page() in fs/btrfs/compression.c)

Point 1 was not causing problem until the incoming large data folio
support, and can be easily fixed with page_pgoff() convertion.


But since we're here, I'm also wondering can we do it better with a
folio or multi-page bvec way?

The current folio bio iteration helper can only start from the beginning
of a bio (bio_for_each_folio_all() and bio_first_folio()), thus it's not
a good fit for point 3.

On the other hand, I'm having some internal code to convert a bio_vec
into a folio and offset inside the folio already.
Thus I'm wondering can we provide something like bio_for_each_folio()?
Or is it too niche that only certain fs can benefit from?

Thanks,
Qu


             reply	other threads:[~2025-03-31 15:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31  8:15 Qu Wenruo [this message]
2025-04-03 17:44 ` Matthew Wilcox
2025-04-04  6:16   ` Christoph Hellwig

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=17517804-1c6b-4b96-a608-8c3d80e5f6dd@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.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