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
