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

[Gregory Price]

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.

> 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.

~Gregory