[PATCH v6 00/33] Split ptdesc from struct page
Hugh Dickins
hughd at google.com
Tue Jun 27 13:25:52 PDT 2023
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
More information about the linux-riscv
mailing list