Re: page->index limitation on 32bit system?

[Matthew Wilcox <willy@infradead.org>]

On Sat, Feb 20, 2021 at 03:02:26PM -0800, Erik Jensen wrote:
> On 2/18/21 5:39 AM, Matthew Wilcox wrote:
> > On Thu, Feb 18, 2021 at 08:42:14PM +0800, Qu Wenruo wrote:
> > > [...]
> > > BTW, what would be the extra cost by converting page::index to u64?
> > > I know tons of printk() would cause warning, but most 64bit systems
> > > should not be affected anyway.
> > 
> > No effect for 64-bit systems, other than the churn.
> > 
> > For 32-bit systems, it'd have some pretty horrible overhead.  You don't
> > just have to touch the page cache, you have to convert the XArray.
> > It's doable (I mean, it's been done), but it's very costly for all the
> > 32-bit systems which don't use a humongous filesystem.  And we could
> > minimise that overhead with a typedef, but then the source code gets
> > harder to work with.
> 
> Out of curiosity, would it be at all feasible to use 64-bits for the page
> offset *without* changing XArray, perhaps by indexing by the lower 32-bits,
> and evicting the page that's there if the top bits don't match (vaguely like
> how the CPU cache works)? Or, if there are cases where a page can't be
> evicted (I don't know if this can ever happen), use chaining?
> 
> I would expect index contention to be extremely uncommon, and it could only
> happen for inodes larger than 16 TiB, which can't be used at all today. I
> don't know how many data structures store page offsets today, but it seems
> like this should significantly reduce the performance impact versus upping
> XArray to 64-bit indexes.

Again, you're asking for significant development work for a dying
platform.

Did you try the bootlin patch?