[0/2] s390: Remove uses of page->index

Message

Matthew Wilcox (Oracle) Dec. 19, 2024, 4:22 p.m. UTC

These two patches compile ... I can promise nothing more than that.

David suggested to me that the gmap code really should be using ptdesc,
and I think I agree with him.  The vsie code looks quite different
and probably shouldn't be using a ptdesc, but we can use page->private
instead of page->index.  It's not yet clear to me if we'll ever manage
to get rid of page->private.

Matthew Wilcox (Oracle) (2):
  s390: Convert gmap code to use ptdesc
  s390: Convert vsie code to use page->private

 arch/s390/kvm/vsie.c |   6 +-
 arch/s390/mm/gmap.c  | 181 +++++++++++++++++++++----------------------
 2 files changed, 92 insertions(+), 95 deletions(-)

Comments

David Hildenbrand Dec. 19, 2024, 4:33 p.m. UTC | #1

On 19.12.24 17:22, Matthew Wilcox (Oracle) wrote:
> These two patches compile ... I can promise nothing more than that.
> 
> David suggested to me that the gmap code really should be using ptdesc,
> and I think I agree with him.  The vsie code looks quite different
> and probably shouldn't be using a ptdesc, but we can use page->private
> instead of page->index.  It's not yet clear to me if we'll ever manage
> to get rid of page->private.

Just curious, does that mean that memdesc would always contain these 
additional 8 bytes?

Matthew Wilcox (Oracle) Dec. 19, 2024, 4:52 p.m. UTC | #2

On Thu, Dec 19, 2024 at 05:33:32PM +0100, David Hildenbrand wrote:
> On 19.12.24 17:22, Matthew Wilcox (Oracle) wrote:
> > These two patches compile ... I can promise nothing more than that.
> > 
> > David suggested to me that the gmap code really should be using ptdesc,
> > and I think I agree with him.  The vsie code looks quite different
> > and probably shouldn't be using a ptdesc, but we can use page->private
> > instead of page->index.  It's not yet clear to me if we'll ever manage
> > to get rid of page->private.
> 
> Just curious, does that mean that memdesc would always contain these
> additional 8 bytes?

Eventually we'll have a choice to make.

1. Shrink struct page to 8 bytes, but we'll need to allocate a 32 byte
   memdesc for all the current users of page->private
2. Shrink struct page to 16 bytes

I genuinely don't know which will be better for the whole system.

If you're asking because we can defer some of the mapcount
work by using the 8 bytes of page->private to store mapcount, then
yes, let's do that.

David Hildenbrand Dec. 19, 2024, 4:56 p.m. UTC | #3

On 19.12.24 17:52, Matthew Wilcox wrote:
> On Thu, Dec 19, 2024 at 05:33:32PM +0100, David Hildenbrand wrote:
>> On 19.12.24 17:22, Matthew Wilcox (Oracle) wrote:
>>> These two patches compile ... I can promise nothing more than that.
>>>
>>> David suggested to me that the gmap code really should be using ptdesc,
>>> and I think I agree with him.  The vsie code looks quite different
>>> and probably shouldn't be using a ptdesc, but we can use page->private
>>> instead of page->index.  It's not yet clear to me if we'll ever manage
>>> to get rid of page->private.
>>
>> Just curious, does that mean that memdesc would always contain these
>> additional 8 bytes?
> 
> Eventually we'll have a choice to make.
> 
> 1. Shrink struct page to 8 bytes, but we'll need to allocate a 32 byte
>     memdesc for all the current users of page->private
> 2. Shrink struct page to 16 bytes
> 
> I genuinely don't know which will be better for the whole system.
> 
> If you're asking because we can defer some of the mapcount
> work by using the 8 bytes of page->private to store mapcount, then
> yes, let's do that.

Yeah, it could give us a bit more time, until we know that we can just 
get rid of it in all kernel configs. But let's see if that is still a 
problem when we're getting closer to removing them.