mbox series

[0/3] minor fixes and supplement for ptdesc

Message ID cover.1709541697.git.zhengqi.arch@bytedance.com (mailing list archive)
Headers show
Series minor fixes and supplement for ptdesc | expand

Message

Qi Zheng March 4, 2024, 11:07 a.m. UTC
Hi all,

In this series, the [PATCH 1/3] and [PATCH 2/3] are fixes for some issues
discovered during code inspection.

The [PATCH 3/3] is a supplement to ptdesc conversion in s390, I don't know
why this is not done in the commit 6326c26c1514 ("s390: convert various pgalloc
functions to use ptdescs"), maybe I missed something. And since I don't have an
s390 environment, I hope kernel test robot can help compile and test, and this
is why I did not fold [PATCH 2/3] and [PATCH 3/3] into one patch.

Comments and suggestions are welcome.

Thanks,
Qi

Qi Zheng (3):
  mm: pgtable: correct the wrong comment about ptdesc->__page_flags
  mm: pgtable: add missing pt_index to struct ptdesc
  s390: supplement for ptdesc conversion

 arch/s390/include/asm/pgalloc.h |  4 ++--
 arch/s390/mm/gmap.c             | 38 +++++++++++++++++----------------
 arch/s390/mm/pgalloc.c          |  8 +++----
 include/linux/mm_types.h        |  5 ++++-
 4 files changed, 30 insertions(+), 25 deletions(-)

Comments

Vishal Moola March 26, 2024, 7:07 p.m. UTC | #1
On Mon, Mar 04, 2024 at 07:07:17PM +0800, Qi Zheng wrote:
> Hi all,

Sorry for the late review. Thanks for looking at doing some ptdesc
conversions. This patchset has the right idea and looks *mostly* fine.

> In this series, the [PATCH 1/3] and [PATCH 2/3] are fixes for some issues
> discovered during code inspection.
> 
> The [PATCH 3/3] is a supplement to ptdesc conversion in s390, I don't know
> why this is not done in the commit 6326c26c1514 ("s390: convert various pgalloc
> functions to use ptdescs"), maybe I missed something. And since I don't have an

It's important to keep in mind the end goal of ptdescs, cleaning up much
of the struct page field misuse by standardizing their usage. s390 page
tables and gmap are similar but not the same, so the conversions require
deeper thought. 

My initial "Split ptdesc from struct page" patchset tried to focus on the
most straightforward, simple conversions in order to introduce the
descriptor and lay a foundation for future conversions - you can see some
more complicated iterations v6 and prior.

When converting to ptdescs (and any other newer descriptors), we should
be careful about generating superficial code churn instead of using
them to solve the problems they are trying to solve.
David Hildenbrand March 27, 2024, 8:52 a.m. UTC | #2
On 26.03.24 20:07, Vishal Moola wrote:
> On Mon, Mar 04, 2024 at 07:07:17PM +0800, Qi Zheng wrote:
>> Hi all,
> 
> Sorry for the late review. Thanks for looking at doing some ptdesc
> conversions. This patchset has the right idea and looks *mostly* fine.
> 
>> In this series, the [PATCH 1/3] and [PATCH 2/3] are fixes for some issues
>> discovered during code inspection.
>>
>> The [PATCH 3/3] is a supplement to ptdesc conversion in s390, I don't know
>> why this is not done in the commit 6326c26c1514 ("s390: convert various pgalloc
>> functions to use ptdescs"), maybe I missed something. And since I don't have an
> 
> It's important to keep in mind the end goal of ptdescs, cleaning up much
> of the struct page field misuse by standardizing their usage. s390 page
> tables and gmap are similar but not the same, so the conversions require
> deeper thought.
> 
> My initial "Split ptdesc from struct page" patchset tried to focus on the
> most straightforward, simple conversions in order to introduce the
> descriptor and lay a foundation for future conversions - you can see some
> more complicated iterations v6 and prior.
> 
> When converting to ptdescs (and any other newer descriptors), we should
> be careful about generating superficial code churn instead of using
> them to solve the problems they are trying to solve.

The gmap shadow pages are page tables that are not linked into the user 
page tables.

I recall I raised in the past that using ptdesc from them is confusing.