From: Christoph Hellwig <hch@infradead.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: Discontiguous folios/pagesets
Date: Wed, 1 Sep 2021 10:40:09 +0100 [thread overview]
Message-ID: <YS9KeV6cwVlBT14R@infradead.org> (raw)
In-Reply-To: <YSqIry5dKg+kqAxJ@casper.infradead.org>
On Sat, Aug 28, 2021 at 08:04:15PM +0100, Matthew Wilcox wrote:
> Non-power-of-two folios are more awkward. Any calls to folio_order()
> and folio_shift() have to be guarded by folio_test_contig() (which will
> be fine). The bigger problem is the radix tree. It really only works
> for power-of-two sized objects (and honestly, it's not even all that
> great for things which aren't a power of 64 in size). See appendix
> for more details.
Honestly I think this framing the wrong problem. Folios are a way
to manage memory which should be about how to manage memory, not about
offloading awkward file systems tasks to performance sensitive core
code.
Right now the proper answer to supporting reflinks on RT devices with
non-power of two extent sizes is don't do it, which is pretty easy
given that XFS doesn't even support reflink on the RT device at all
yet. And if someone has a strong enough use case for eflinks on a weird
extent size RT device they'll find way to support it, preferably
without making a mess out of the core Linux memory management. Because
even if we did support non-power of two folios sizes we'd still need
to gurantee XFS would always be able to allocate one for that case,
which just sounds like a trainwreck waiting to happen.
prev parent reply other threads:[~2021-09-01 9:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-28 19:04 Discontiguous folios/pagesets Matthew Wilcox
2021-08-28 19:27 ` Andreas Dilger
2021-08-30 18:28 ` Darrick J. Wong
2021-08-30 18:35 ` Andreas Dilger
2021-08-30 18:43 ` Matthew Wilcox
2021-09-01 9:40 ` Christoph Hellwig [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=YS9KeV6cwVlBT14R@infradead.org \
--to=hch@infradead.org \
--cc=darrick.wong@oracle.com \
--cc=hannes@cmpxchg.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.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.