[LSF/MM/BPF TOPIC] Gathering ideas to reduce ZONE_NORMAL cost

[Byungchul Park <byungchul@sk.com>]

On Fri, Feb 21, 2025 at 10:52:09AM +0900, Harry Yoo wrote:
> On Mon, Feb 10, 2025 at 10:47:58AM -0500, Gregory Price wrote:
> > On Mon, Feb 10, 2025 at 04:17:41PM +0900, Byungchul Park wrote:
> > > On Mon, Feb 10, 2025 at 01:00:02AM -0500, Gregory Price wrote:
> > > > 
> > > >    You can probably actually (maybe?) collect data on this today - but
> > > >    you still have to contend with #2 and #3.
> > > 
> > > Ah.  You seem to mean those works should be serialized.  Right?  If it
> > > should be for some reason, then it could be sensible.
> > > 
> > 
> > I'm suggesting that there isn't a strong reason (yet) to consider such a
> > complicated change.  As Willy has said, it's a fairly fundamental change
> > for a single-reason (CXL), which does not bode well for its acceptance.
> > 
> > Honestly trying to save you some frustration. It would behoove you to
> > find stronger reasons (w/ data) or consider different solutions. Right
> > now there are stronger, simplers solutions to the ZONE_NORMAL capacity
> > issue (struct page resize, huge pages) for possible capacities.
> 
> Hi, apologies for my late reply. I recently went through a career change.
> 
> I truly appreciate your and Matthew's feedback and thank you for saving us
> from frustration. I agree that we need a stronger motivation
> and data to introduce such a fundamental change. And I also agree that
> it's more appropriate to pursue what can be useful for genral MM users
> rather than introducing MM changes just for CXL.
> 
> With that context, Byungchul and I agree it's a better direction:
> Reducing ZONE_NORMAL cost for ZONE_MOVABLE capacity, which is beneficial
> for ZONE_MOVABLE users in general, regardless of whether the user is using
> CXL memory or not.
> 
> Let me organize a few steps to pursue:
> 
> - Willy's shrinking struct page project
>   - https://fosdem.org/2025/schedule/event/fosdem-2025-4860-shrinking-memmap/ 
>   - https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
>   - Side note: Byungchul started working on separating the descriptor
>     of the pagepool bump allocator
> 
> - Slab Movable Objects: This makes sense even without CXL
>   as migrating unreclaimable slab will improve compaction success rate.
>   It also has been tried in the past by others, but was suspended
>   due to lack of data.
>   
>   I'm looking for workloads that allocate a decent amount of unreclaimable
>   slab AND performs migration frequently - for evaluation.
> 
> I might be missing some projects that could be useful,
> please feel free to add if there is any.

So..  Let's change the LSF/MM/BPF topic slightly.

	Byungchul

> And for page table migration, while it might be doable even without CXL,
> we need strong data that suggests that it's actually makes MM better
> to pursue this.
> 
> > I also think someone should actively ask whether `struct page` can be
> > hosted on remote memory without performance loss.  I may look into this.
> 
> Did you have a chance to look at this?
> 
> -- 
> Cheers,
> Harry