Re: Removing page->index

[Claudio Imbrenda <imbrenda@linux.ibm.com>]

On Wed, 4 Dec 2024 16:58:52 +0100
David Hildenbrand <david@redhat.com> wrote:

> On 03.12.24 20:51, Matthew Wilcox wrote:
> > I've pushed out a new tree to
> > git://git.infradead.org/users/willy/pagecache.git shrunk-page
> > aka
> > http://git.infradead.org/?p=users/willy/pagecache.git;a=shortlog;h=refs/heads/shrunk-page
> > 
> > The observant will notice that it doesn't actually shrink struct page
> > yet.  However, we're getting close.  What it does do is rename
> > page->index to page->__folio_index to prevent new users of page->index
> > from showing up.  
> 
> BTW, I was wondering how often we convert a page to a folio to then 
> access folio->index / folio->mapping and not actually having a folio (in 
> the future).
> 
> I suspect this will need quite some changes to get it right, and I would 
> count that as "less obvious".
> 
> Calling PageAnon() on anything mapped into user space page tables might 
> be one such case, for example.
> 
> > 
> > There are (I believe) three build failures in that tree:
> > 
> >   - fb_defio
> >   - fbtft
> >   - s390's gmap (and vsie?  is that the same thing?)  
> 
> Not completely (vsie (nested VMs) uses shadow gmap, ordinary VMs use 
> ordinary gmap) , but they are very related (-> KVM implementation on s390x).
> 
> I know that Claudio is working on some changes, but not sure how that 
> would affect gmap's usage of page->index.

After I'm done, we won't use page->index anymore.

The changes I'm working on are massive, it's very impractical to push
everything at once, so I'm refactoring and splitting smaller and more
manageable (and reviewable) series.

This means that it will take some time before I'm done (I'm *hoping*
to be done for 6.15)

> 
> s390x gmap is 64bit only, so we have to store stuff in 8byte. gmap page 
> tables are
> 
> Maybew e could simply switch from page->index to page->private? But I 
> lost track if that will also be gone in the near future :)
> 
> > 
> > Other than that, allmodconfig builds on x86 and I'm convinced the build
> > bots will tell me about anything else I missed.
> > 
> > Lorenzo is working on fb_defio and fbtft will come along for the ride
> > (it's a debug printk, so could just be deleted).
> > 
> > s390 is complicated.  I'd really appreciate some help.
> > 
> > The next step is to feed most of the patches through the appropriate
> > subsystems.  Some have already gone into various maintainer trees
> > (thanks!)
> > 
> > 
> > There are still many more steps to go after this; eliminating memcg_data
> > is closest to complete, and after that will come (in some order)
> > eliminating ->lru, ->mapping, ->refcount and ->mapcount.   
> 
> Will continue working on the latter ;)
>