Re: [PATCH v6 00/33] Split ptdesc from struct page
David Hildenbrand <[email protected]>
| Newsgroups | gmane.linux.ports.riscv,gmane.linux.kernel.mm,gmane.linux.kernel.cross-arch,gmane.linux.ports.arm.kernel,gmane.linux.ports.hexagon,gmane.linux.ports.mips,gmane.linux.ports.ppc64.devel,gmane.linux.ports.sh.devel,gmane.linux.ports.sparc,gmane.linux.uml.devel,gmane.comp.emulators.xen.devel,gmane.comp.emulators.kvm.devel |
|---|---|
| Organization | Red Hat |
| Message-ID | <[email protected]> |
On 27.06.23 22:13, Hugh Dickins wrote: > On Tue, 27 Jun 2023, David Hildenbrand wrote: >> On 27.06.23 06:44, 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. >> >> I share your thoughts, that code churn which will help eventually in the far, >> far future (not wanting to sound too pessimistic, but it's not going to be >> there tomorrow ;) ). >> >> However, if it's just the same as the other conversions we already did (e.g., >> struct slab), then I guess there is no reason to stop now -- the obfuscation >> already happened. >> >> ... or is there a difference regarding this conversion and the previous ones? > > I was aware of the struct slab thing, didn't see much point there myself > either; but it was welcomed by Vlastimil, and barely affected outside of > slab allocators, so I had no reason to object. > > You think that if a little unnecessary churn (a *lot* of churn if you > include folios, which did save some repeated calls to compound_head()) > has already occurred, that's a good precedent for allowing more and more? Well, if you phrase it like that ... no, I'm not in favor of unnecessary churn at all. Yes, folios were/are a lot of churn (IMHO not unnecessary, though). I'm not a friend of these "overlays"; it all only really makes sense to me once we actually allocate the descriptors dynamically. Maybe some of the existing/ongoing conversions were different (that's why I was asking for the difference, as you said the "struct slab" thing was well received). If they are primarily only unnecessary churn for now (and unclear when/how it will become useful), I share your opinion. -- Cheers, David / dhildenb