Re: [PATCH v2 2/4] mm: allow shared folios to be promoted to a fast tier

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Sep 17, 2026 at 12:18:24PM -0400, Gregory Price wrote:
> On Thu, Sep 17, 2026 at 06:08:27PM +0200, Peter Zijlstra wrote:
> > > diff --git a/mm/migrate.c b/mm/migrate.c
> > > index a369d0c95c38..afd9c97d2389 100644
> > > --- a/mm/migrate.c
> > > +++ b/mm/migrate.c
> > > @@ -2697,12 +2697,14 @@ int migrate_misplaced_folio_prepare(struct folio *folio,
> > >  		/*
> > >  		 * Do not migrate file folios that are mapped in multiple
> > >  		 * processes with execute permissions as they are probably
> > > -		 * shared libraries.
> > > +		 * shared libraries, unless this is a promotion from a slow tier.
> > >  		 *
> > >  		 * See folio_maybe_mapped_shared() on possible imprecision
> > >  		 * when we cannot easily detect if a folio is shared.
> > >  		 */
> > > -		if ((vma->vm_flags & VM_EXEC) && folio_maybe_mapped_shared(folio))
> > > +		if ((vma->vm_flags & VM_EXEC) &&
> > > +		    folio_maybe_mapped_shared(folio) &&
> > > +		    (!folio_use_access_time(folio) || !node_is_toptier(node)))
> > >  			return -EACCES;
> > >  
> > 
> > Semi related; I've often wondered if we should still account shared and
> > pinned vmas in the fault statistic, even though we should not migrate
> > them.
> > 
> > After all, those pages are still used and by not accounting them in the
> > fault statistics, it becomes easier to migrate a task away from them.
> >
> 
> I don't have a strong opinion here to be honest, I'm just trying to get
> tiering back on track.  There's some scheduler voodoo there that I will
> happily claim ignorance on, so I just tried to keep things as-is here.

Yeah, fair enough.

> > Using the scanning for two different things has made a mess of things
> > though :/
> 
> This has been my takeaway from this fix as well.
> 
> Honestly I'm starting to think hint faults are a big hammer making up
> for the lack of hardware support for getting this data.
> 
> Would be nice to just have the hardware report what's hot (and how hot)
> rather than depending on a software-heuristic like deriving hotness
> from a page fault.

Yeah, there is/was this patch-set from AMD that uses their IBS counters
for this, but 'ab'-using the performance counters for this also has ick.
PMU data isn't ideal either. Mostly they generate a ton of data that
needs to be analyzed as well. Its not clear cut and easy.

I'm not sure there's been proposals for better hardware support.