[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240617065104.GA18547@lst.de>
Date: Mon, 17 Jun 2024 08:51:04 +0200
From: Christoph Hellwig <hch@....de>
To: Dave Chinner <david@...morbit.com>
Cc: Christoph Hellwig <hch@....de>,
"Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>,
djwong@...nel.org, chandan.babu@...cle.com, brauner@...nel.org,
akpm@...ux-foundation.org, willy@...radead.org, mcgrof@...nel.org,
linux-mm@...ck.org, hare@...e.de, linux-kernel@...r.kernel.org,
yang@...amperecomputing.com, Zi Yan <zi.yan@...t.com>,
linux-xfs@...r.kernel.org, p.raghav@...sung.com,
linux-fsdevel@...r.kernel.org, gost.dev@...sung.com,
cl@...amperecomputing.com, john.g.garry@...cle.com
Subject: Re: [PATCH v7 11/11] xfs: enable block size larger than page size
support
On Mon, Jun 17, 2024 at 11:29:42AM +1000, Dave Chinner wrote:
> > > + if (mp->m_sb.sb_blocksize > PAGE_SIZE)
> > > + igeo->min_folio_order = mp->m_sb.sb_blocklog - PAGE_SHIFT;
> > > + else
> > > + igeo->min_folio_order = 0;
> > > }
> >
> > The minimum folio order isn't really part of the inode (allocation)
> > geometry, is it?
>
> I suggested it last time around instead of calculating the same
> constant on every inode allocation. We're already storing in-memory
> strunct xfs_inode allocation init values in this structure. e.g. in
> xfs_inode_alloc() we see things like this:
While new_diflags2 isn't exactly inode geometry, it at least is part
of the inode allocation. Folio min order for file data has nothing
to do with this at all.
> The only other place we might store it is the struct xfs_mount, but
> given all the inode allocation constants are already in the embedded
> mp->m_ino_geo structure, it just seems like a much better idea to
> put it will all the other inode allocation constants than dump it
> randomly into the struct xfs_mount....
Well, it is very closely elated to say the m_blockmask field in
struct xfs_mount. The again modern CPUs tend to get a you simple
subtraction for free in most pipelines doing other things, so I'm
not really sure it's worth caching for use in inode allocation to
start with, but I don't care strongly about that.
Powered by blists - more mailing lists