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?
