Re: [PATCH v6 00/33] Split ptdesc from struct page

Hugh Dickins
2023-06-27T20:26:02Z

On Tue, 27 Jun 2023, Matthew Wilcox wrote:
> On Mon, Jun 26, 2023 at 09:44:08PM -0700, Hugh Dickins wrote:
> > On Mon, 26 Jun 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.
> > ...
> > > 39 files changed, 686 insertions(+), 455 deletions(-)
> >
> > I don't see the point of this patchset: to me it is just obfuscation of
> > the present-day tight relationship between page table and struct page.
> >
> > Matthew already explained:
> >
> > > The intent is to get ptdescs to be dynamically allocated at some point
> > > in the ~2-3 years out future when we have finished the folio project ...
> >
> > So in a kindly mood, I'd say that this patchset is ahead of its time.
> > But I can certainly adapt to it, if everyone else sees some point to it.
>
> If you think this patchset is ahead of its time, we can certainly put
> it on hold. We're certainly prepared to redo it to be merged after your
> current patch series.

Thank you, but I can adapt. That was not my point:
I'm claiming this patchset is ~2-3 years ahead of its time.

>
> I think you can see the advantage of the destination, so I don't think
> you're against that.

Maybe - I have some scepticism, but I'll be happy for that to be dissolved.

> Are you opposed to the sequencing of the work to
> get us there? I'd be happy to discuss another way to do it.

Yes, I'm opposed to churn for no benefit.

>
> For example, we could dynamically allocate ptdescs right now. We'd get
> the benefit of having an arbitrary amount of space in the ptdesc,
> although not the benefit of a smaller memmap until everything else is
> also dynamically allocated.

That sounded much better, at first: churn serving good purpose. But now
I suspect you're offering to dynamically allocate a ptdesc, in addition
to the struct page of the page table(s) itself, which will be wasted:
more memory consumption to no advantage. If that's so, no thanks.

Hugh