From: David Sterba <dsterba@suse.cz>
To: Neal Gompa <neal@gompa.dev>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>,
linux-btrfs@vger.kernel.org,
Goldwyn Rodrigues <rgoldwyn@suse.com>,
Josef Bacik <josef@toxicpanda.com>
Subject: Re: [PATCH v2 0/3] page to folio conversion
Date: Wed, 31 Jan 2024 07:13:02 +0100 [thread overview]
Message-ID: <20240131061302.GF31555@suse.cz> (raw)
In-Reply-To: <CAEg-Je8L1B0JHmmcir5GpThPqACpLXm13sT6v2yS4pV_4Ty+0g@mail.gmail.com>
On Wed, Jan 31, 2024 at 04:29:36AM +0000, Neal Gompa wrote:
> On Mon, Jan 29, 2024 at 8:05 AM David Sterba <dsterba@suse.cz> wrote:
> >
> > On Tue, Jan 23, 2024 at 01:28:04PM -0600, Goldwyn Rodrigues wrote:
> > > From: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > >
> > > These patches transform some page usage to folio. All references and data
> > > of page/folio is within the scope of the function changed.
> > >
> > > Changes since v1:
> > > Review comments -
> > > * Added WARN_ON(folio_order(folio)) to ensure future development knows
> > > this code assumes folio_size(folio) == PAGE_SIZE
> > > * namespace restoration: prefix variable names with folio_
> > > * Line adjustments
> > >
> > > Goldwyn Rodrigues (3):
> > > btrfs: page to folio conversion: prealloc_file_extent_cluster()
> > > btrfs: convert relocate_one_page() to relocate_one_folio()
> > > btrfs: page to folio conversion in put_file_data()
> >
> > The conversion looks straightforward like we've been doing elsewhere,
> > however the CI is still not in a shape to validate arm + subpage, I've
> > seen the hosts not pass with various sets of patches (removed potential
> > breakage and keeping potential fixes).
> >
> > There are more folio conversions coming so I'd like to get them all in
> > so we can switch to the big folios eventually but without the CI
> > verification of subpage it's a bit risky.
> >
>
> Wait, we don't? I thought Josef had specifically added Fedora Asahi
> runners specifically for subpage testing[1]?
Yes, but we don't have yet a stable testing base with all-pass results
on all configuration and with quirks disabling unreliable tests. There
are crashes reported with various sets of patches that are likely
caused by folio changes but it's hard to narrow down which ones.
next prev parent reply other threads:[~2024-01-31 6:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 19:28 [PATCH v2 0/3] page to folio conversion Goldwyn Rodrigues
2024-01-23 19:28 ` [PATCH 1/3] btrfs: page to folio conversion: prealloc_file_extent_cluster() Goldwyn Rodrigues
2024-01-23 19:28 ` [PATCH 2/3] btrfs: convert relocate_one_page() to relocate_one_folio() Goldwyn Rodrigues
2024-01-23 19:28 ` [PATCH 3/3] btrfs: page to folio conversion in put_file_data() Goldwyn Rodrigues
2024-01-29 8:04 ` [PATCH v2 0/3] page to folio conversion David Sterba
2024-01-31 4:29 ` Neal Gompa
2024-01-31 6:13 ` David Sterba [this message]
2024-03-26 15:17 ` 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=20240131061302.GF31555@suse.cz \
--to=dsterba@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=neal@gompa.dev \
--cc=rgoldwyn@suse.com \
--cc=rgoldwyn@suse.de \
/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