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

From: Erik Jensen <erikjensen@rkjnsn.net>
To: Matthew Wilcox <willy@infradead.org>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: page->index limitation on 32bit system?
Date: Sat, 20 Feb 2021 16:01:17 -0800	[thread overview]
Message-ID: <CAMj6ewPxYkoPuVmER7QuBfyDK4O9Ksr4OZTiGkpGvbg4kmxh6A@mail.gmail.com> (raw)
In-Reply-To: <20210220232224.GF2858050@casper.infradead.org>

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.

> Did you try the bootlin patch?

While looking into it, I discovered that btrfs can't currently handle
mounting a filesystem that was created on a system with a different
page size. However, it sounds like there is currently work being done
to support subpage sector sizes, with read-only support coming in 3.12
and write support coming later, so hopefully the bootlin patch will be
helpful to bump my page size up to 64 KiB once btrfs support for it is
fully stable. Thanks!

It does feel like I'd just be kicking the can down the road a bit, but
hopefully it will turn out to be long enough for there to be either a
better fix or an AArch64 system that meets my needs by then (e.g., if
Kobol were to release a version of the Helios64 with ECC RAM).

I do appreciate your help and explanations.

Thanks!