From: "Darrick J. Wong" <djwong@kernel.org>
To: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>
Cc: david@fromorbit.com, willy@infradead.org, ryan.roberts@arm.com,
linux-kernel@vger.kernel.org, yang@os.amperecomputing.com,
linux-mm@kvack.org, john.g.garry@oracle.com,
linux-fsdevel@vger.kernel.org, hare@suse.de,
p.raghav@samsung.com, mcgrof@kernel.org, gost.dev@samsung.com,
cl@os.amperecomputing.com, linux-xfs@vger.kernel.org, hch@lst.de,
Zi Yan <zi.yan@sent.com>,
akpm@linux-foundation.org, chandan.babu@oracle.com
Subject: Re: [PATCH v8 01/10] fs: Allow fine-grained control of folio sizes
Date: Tue, 9 Jul 2024 14:59:18 -0700 [thread overview]
Message-ID: <20240709215918.GD612460@frogsfrogsfrogs> (raw)
In-Reply-To: <20240709210829.dgm6dsirkry3fgu6@quentin>
On Tue, Jul 09, 2024 at 09:08:29PM +0000, Pankaj Raghav (Samsung) wrote:
> > >
> > > - We make THP an explicit dependency for XFS:
> > >
> > > diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig
> > > index d41edd30388b7..be2c1c0e9fe8b 100644
> > > --- a/fs/xfs/Kconfig
> > > +++ b/fs/xfs/Kconfig
> > > @@ -5,6 +5,7 @@ config XFS_FS
> > > select EXPORTFS
> > > select LIBCRC32C
> > > select FS_IOMAP
> > > + select TRANSPARENT_HUGEPAGE
> > > help
> > > XFS is a high performance journaling filesystem which originated
> > > on the SGI IRIX platform. It is completely multi-threaded, can
> > >
> > > OR
> > >
> > > We create a helper in page cache that FSs can use to check if a specific
> > > order can be supported at mount time:
> >
> > I like this solution better; if XFS is going to drop support for o[ld]d
> > architectures I think we need /some/ sort of notice period. Or at least
> > a better story than "we want to support 64k fsblocks on x64 so we're
> > withdrawing support even for 4k fsblocks and smallish filesystems on
> > m68k".
> >
> > You probably don't want bs>ps support to block on some arcane discussion
> > about 32-bit, right? ;)
> >
>
> :)
>
> > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> > > index 14e1415f7dcf..9be775ef11a5 100644
> > > --- a/include/linux/pagemap.h
> > > +++ b/include/linux/pagemap.h
> > > @@ -374,6 +374,14 @@ static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask)
> > > #define MAX_XAS_ORDER (XA_CHUNK_SHIFT * 2 - 1)
> > > #define MAX_PAGECACHE_ORDER min(MAX_XAS_ORDER, PREFERRED_MAX_PAGECACHE_ORDER)
> > >
> > > +
> > > +static inline unsigned int mapping_max_folio_order_supported()
> > > +{
> > > + if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
> > > + return 0;
> >
> > Shouldn't this line be indented by two tabs, not six spaces?
> >
> > > + return MAX_PAGECACHE_ORDER;
> > > +}
> >
> > Alternately, should this return the max folio size in bytes?
> >
> > static inline size_t mapping_max_folio_size(void)
> > {
> > if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
> > return 1U << (PAGE_SHIFT + MAX_PAGECACHE_ORDER);
> > return PAGE_SIZE;
> > }
>
> We already have mapping_max_folio_size(mapping) which returns the
> maximum folio order set for that mapping. So this could be called as
> mapping_max_folio_size_supported().
>
> So we could just have mapping_max_folio_size_supported() instead of
> having mapping_max_folio_order_supported as you suggest.
<nod>
> >
> > Then the validation looks like:
> >
> > const size_t max_folio_size = mapping_max_folio_size();
> >
> > if (mp->m_sb.sb_blocksize > max_folio_size) {
> > xfs_warn(mp,
> > "block size (%u bytes) not supported; maximum folio size is %u.",
> > mp->m_sb.sb_blocksize, max_folio_size);
> > error = -ENOSYS;
> > goto out_free_sb;
> > }
> >
> > (Don't mind me bikeshedding here.)
> >
> > > +
> > >
> > >
> > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> > > index b8a93a8f35cac..e2be8743c2c20 100644
> > > --- a/fs/xfs/xfs_super.c
> > > +++ b/fs/xfs/xfs_super.c
> > > @@ -1647,6 +1647,15 @@ xfs_fs_fill_super(
> > > goto out_free_sb;
> > > }
> > >
> > > + if (mp->m_sb.sb_blocklog - PAGE_SHIFT >
> > > + mapping_max_folio_order_supported()) {
> > > + xfs_warn(mp,
> > > +"Block Size (%d bytes) is not supported. Check MAX_PAGECACHE_ORDER",
> > > + mp->m_sb.sb_blocksize);
> >
> > You might as well print MAX_PAGECACHE_ORDER here to make analysis
> > easier on less-familiar architectures:
>
> Yes!
Thanks.
--D
> >
> > xfs_warn(mp,
> > "block size (%d bytes) is not supported; max folio size is %u.",
> > mp->m_sb.sb_blocksize,
> > 1U << mapping_max_folio_order_supported());
> >
> > (I wrote this comment first.)
>
> >
> > --D
> >
> > > + error = -ENOSYS;
> > > + goto out_free_sb;
> > > + }
> > > +
> > > xfs_warn(mp,
> > > "EXPERIMENTAL: V5 Filesystem with Large Block Size (%d bytes) enabled.",
> > > mp->m_sb.sb_blocksize);
> > >
> > >
> > > --
> > > Pankaj
>
next prev parent reply other threads:[~2024-07-09 21:59 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 11:44 [PATCH v8 00/10] enable bs > ps in XFS Pankaj Raghav (Samsung)
2024-06-25 11:44 ` [PATCH v8 01/10] fs: Allow fine-grained control of folio sizes Pankaj Raghav (Samsung)
2024-07-04 12:23 ` Ryan Roberts
2024-07-04 15:20 ` Matthew Wilcox
2024-07-04 15:52 ` Ryan Roberts
2024-07-04 21:28 ` Pankaj Raghav (Samsung)
2024-07-04 22:06 ` Dave Chinner
2024-07-04 23:56 ` Matthew Wilcox
2024-07-05 4:32 ` Dave Chinner
2024-07-05 9:03 ` Ryan Roberts
2024-07-05 12:45 ` Pankaj Raghav (Samsung)
2024-07-05 13:24 ` Pankaj Raghav (Samsung)
2024-07-05 13:31 ` Ryan Roberts
2024-07-05 14:14 ` Pankaj Raghav (Samsung)
2024-07-08 23:01 ` Dave Chinner
2024-07-09 8:11 ` Ryan Roberts
2024-07-09 13:08 ` Pankaj Raghav (Samsung)
2024-07-05 15:14 ` Matthew Wilcox
2024-07-04 21:34 ` Pankaj Raghav (Samsung)
2024-07-09 16:29 ` Pankaj Raghav (Samsung)
2024-07-09 16:38 ` Matthew Wilcox
2024-07-09 17:33 ` Pankaj Raghav (Samsung)
2024-07-09 16:50 ` Darrick J. Wong
2024-07-09 21:08 ` Pankaj Raghav (Samsung)
2024-07-09 21:59 ` Darrick J. Wong [this message]
2024-06-25 11:44 ` [PATCH v8 02/10] filemap: allocate mapping_min_order folios in the page cache Pankaj Raghav (Samsung)
2024-06-25 15:52 ` Matthew Wilcox
2024-06-25 18:06 ` Pankaj Raghav (Samsung)
2024-06-25 11:44 ` [PATCH v8 03/10] readahead: allocate folios with mapping_min_order in readahead Pankaj Raghav (Samsung)
2024-07-02 19:38 ` Darrick J. Wong
2024-07-03 14:10 ` Pankaj Raghav (Samsung)
2024-07-04 14:24 ` Ryan Roberts
2024-07-04 14:29 ` Matthew Wilcox
2024-06-25 11:44 ` [PATCH v8 04/10] mm: split a folio in minimum folio order chunks Pankaj Raghav (Samsung)
2024-06-25 14:45 ` Zi Yan
2024-06-25 17:20 ` Pankaj Raghav (Samsung)
2024-06-25 11:44 ` [PATCH v8 05/10] filemap: cap PTE range to be created to allowed zero fill in folio_map_range() Pankaj Raghav (Samsung)
2024-07-01 23:39 ` Darrick J. Wong
2024-06-25 11:44 ` [PATCH v8 06/10] iomap: fix iomap_dio_zero() for fs bs > system page size Pankaj Raghav (Samsung)
2024-07-01 2:37 ` Dave Chinner
2024-07-01 11:22 ` Pankaj Raghav (Samsung)
2024-07-01 23:40 ` Darrick J. Wong
2024-07-02 7:42 ` Christoph Hellwig
2024-07-02 10:15 ` Pankaj Raghav (Samsung)
2024-07-02 12:02 ` Christoph Hellwig
2024-07-02 14:01 ` Pankaj Raghav (Samsung)
2024-07-02 15:42 ` Christoph Hellwig
2024-07-02 16:13 ` Pankaj Raghav (Samsung)
2024-07-02 16:51 ` Matthew Wilcox
2024-07-02 17:10 ` Pankaj Raghav (Samsung)
2024-07-03 5:16 ` Christoph Hellwig
2024-07-02 16:50 ` Matthew Wilcox
2024-07-02 13:49 ` Luis Chamberlain
2024-06-25 11:44 ` [PATCH v8 07/10] xfs: use kvmalloc for xattr buffers Pankaj Raghav (Samsung)
2024-06-25 18:07 ` Pankaj Raghav (Samsung)
2024-06-25 11:44 ` [PATCH v8 08/10] xfs: expose block size in stat Pankaj Raghav (Samsung)
2024-07-01 2:33 ` Dave Chinner
2024-06-25 11:44 ` [PATCH v8 09/10] xfs: make the calculation generic in xfs_sb_validate_fsb_count() Pankaj Raghav (Samsung)
2024-07-01 2:34 ` Dave Chinner
2024-06-25 11:44 ` [PATCH v8 10/10] xfs: enable block size larger than page size support Pankaj Raghav (Samsung)
2024-07-01 2:34 ` Dave Chinner
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=20240709215918.GD612460@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=chandan.babu@oracle.com \
--cc=cl@os.amperecomputing.com \
--cc=david@fromorbit.com \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=kernel@pankajraghav.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=p.raghav@samsung.com \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.org \
--cc=yang@os.amperecomputing.com \
--cc=zi.yan@sent.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.