Removing page->index

Removing page->index

[Matthew Wilcox]

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.

There are (I believe) three build failures in that tree:

 - fb_defio
 - fbtft
 - s390's gmap (and vsie?  is that the same thing?)

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.  We also need
to move page_pool out into its own structure.

Re: Removing page->index

[Thomas Zimmermann]

Hi


Am 03.12.24 um 20:51 schrieb Matthew Wilcox:
> 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.
>
> There are (I believe) three build failures in that tree:
>
>   - fb_defio

It's only used for helpers of the mm code. So it should be good to change.

>   - fbtft

And this reference should be removed IMHO. The driver's display-update 
code has no business in looking at struct page.

Best regards
Thomas

>   - s390's gmap (and vsie?  is that the same thing?)
>
> 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.  We also need
> to move page_pool out into its own structure.

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: Removing page->index

[David Hildenbrand]

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.

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 ;)

-- 
Cheers,

David / dhildenb

Re: Removing page->index

[Claudio Imbrenda]

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 ;)
> 

Re: Removing page->index

[David Hildenbrand]

On 09.12.24 18:36, Claudio Imbrenda wrote:
> 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)

Thanks for the information. So for the time being, we could likely 
switch to page->private.

One question may be whether these (not-user-space) page tables should at 
some point deserve a dedicated memdesc. But likely the question is what 
it will all look like after your rework.

-- 
Cheers,

David / dhildenb

Re: Removing page->index

[Claudio Imbrenda]

On Tue, 10 Dec 2024 12:05:25 +0100
David Hildenbrand <david@redhat.com> wrote:

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

[...]

> >> 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)  
> 
> Thanks for the information. So for the time being, we could likely 
> switch to page->private.
> 
> One question may be whether these (not-user-space) page tables should at 
> some point deserve a dedicated memdesc. But likely the question is what 

maybe? but given that everything is changing all the time, I'm avoiding
any magic logic in struct page / struct folio.

> it will all look like after your rework.

but now that you put my attention on it, I'll try to get rid of
page->index rather sooner than later.

Re: Removing page->index

[David Hildenbrand]

On 10.12.24 13:04, Claudio Imbrenda wrote:
> On Tue, 10 Dec 2024 12:05:25 +0100
> David Hildenbrand <david@redhat.com> wrote:
> 
>> On 09.12.24 18:36, Claudio Imbrenda wrote:
>>> On Wed, 4 Dec 2024 16:58:52 +0100
>>> David Hildenbrand <david@redhat.com> wrote:
> 
> [...]
> 
>>>> 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)
>>
>> Thanks for the information. So for the time being, we could likely
>> switch to page->private.
>>
>> One question may be whether these (not-user-space) page tables should at
>> some point deserve a dedicated memdesc. But likely the question is what
> 
> maybe? but given that everything is changing all the time, I'm avoiding
> any magic logic in struct page / struct folio.

I think Willy wants to get rid of page->index in the next release, so 
any way to avoid the page->index usage in s390x is appreciated. 
page->private might be the low hanging fruit. If your approach is 
feasible in that time frame, it would also be great.

-- 
Cheers,

David / dhildenb