Re: [PATCH mm-unstable v7 00/31] Split ptdesc from struct page

[Matthew Wilcox <willy@xxxxxxxxxxxxx>]

On Mon, Jul 24, 2023 at 09:41:36PM -0700, Hugh Dickins wrote:
> On Mon, 24 Jul 2023, Vishal Moola (Oracle) wrote:
> 
> > The MM subsystem is trying to shrink struct page. This patchset
> > introduces a memory descriptor for page table tracking - struct ptdesc.
> > 
> > This patchset introduces ptdesc, splits ptdesc from struct page, and
> > converts many callers of page table constructor/destructors to use ptdescs.
> > 
> > Ptdesc is a foundation to further standardize page tables, and eventually
> > allow for dynamic allocation of page tables independent of struct page.
> > However, the use of pages for page table tracking is quite deeply
> > ingrained and varied across archictectures, so there is still a lot of
> > work to be done before that can happen.
> 
> Others may differ, but it remains the case that I see no point to this
> patchset, until the minimal descriptor that replaces struct page is
> working, and struct page then becomes just overhead.  Until that time,
> let architectures continue to use struct page as they do - whyever not?

Because it's easier for architecture maintainers to understand what they
should and shouldn't be using.  Look at the definition:

+struct ptdesc {
+       unsigned long __page_flags;
+
+       union {
+               struct rcu_head pt_rcu_head;
+               struct list_head pt_list;
+               struct {
+                       unsigned long _pt_pad_1;
+                       pgtable_t pmd_huge_pte;
+               };
+       };
+       unsigned long __page_mapping;
+
+       union {
+               struct mm_struct *pt_mm;
+               atomic_t pt_frag_refcount;
+       };
+
+       union {
+               unsigned long _pt_pad_2;
+#if ALLOC_SPLIT_PTLOCKS
+               spinlock_t *ptl;
+#else
+               spinlock_t ptl;
+#endif
+       };
+       unsigned int __page_type;
+       atomic_t _refcount;
+#ifdef CONFIG_MEMCG
+       unsigned long pt_memcg_data;
+#endif
+};

It's still a 31-line struct definition, I'll grant you.  But it's far
easier to comprehend than the definition of struct page (~140 lines).
An architecture maintainer can look at it and see what might be available,
and what is already used.  And hopefully we'll have less "Oh, I'll just
use page->private".  It's really not fair to expect arch maintainers to
learn so much about the mm.

It's still messier than I would like, but I don't think we can do better
for now.  I don't understand why you're so interested in delaying doing
this work.