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

[Matthew Wilcox <willy@infradead.org>]

On Sat, Feb 20, 2021 at 04:01:17PM -0800, Erik Jensen wrote:
> On Sat, Feb 20, 2021 at 3:23 PM Matthew Wilcox <willy@infradead.org> wrote:
> > On Sat, Feb 20, 2021 at 03:02:26PM -0800, Erik Jensen wrote:
> > > 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.
> 
> Depending on how complex it would be, I'm not unwilling to give it a
> go myself, but I admittedly have no kernel development experience or
> knowledge of how locking works around the page cache. E.g., I have no
> idea if evicting the old page at an index before bringing in a new one
> is even possible without causing deadlocks right and left.

I wouldn't recommend the page cache as the ideal place to start learning
how to hack on the kernel.  Not only is it complex, it affects almost
everything.

What might work is using "auxiliary" inodes for btrfs's special purpose.
Allocate an array of inodes and use inodes[index / (ULONG_MAX + 1)]
and look up the page at index % (ULONG_MAX + 1).