Re: [PATCH v8 01/10] fs: Allow fine-grained control of folio sizes

Darrick J. Wong
2024-07-09T21:59:22Z

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
>