Re: [PATCH 2/2] sched/numa: scan read-only file mappings in tiering mode

[Gregory Price]

On Fri, Sep 04, 2026 at 03:31:19PM -0400, Gregory Price wrote:
> On Fri, Sep 04, 2026 at 02:20:06PM -0400, Gregory Price wrote:
> > @@ -4302,7 +4316,7 @@ static void task_numa_work(struct callback_head *work)
> >  		 * VMA can cause others to become "permanently unaccessed" if a scan
> >  		 * cycle is consumed entirely by the large VMA.
> >  		 */
> > -		vma->numab_state->slow_only = false;
> > +		vma->numab_state->slow_only = ro_file;
> >  		if (!vma_pids_forced && !vma_is_accessed(mm, vma)) {
> >  			if (!(sysctl_numa_balancing_mode &
> >  			      NUMA_BALANCING_MEMORY_TIERING)) {
> 
> Sashiko thinks this causes unneeded rescanning, but I don't think it
> does. The cursor prevents it from restarting, and when we loop back
> around reset_ptenuma_scan() bumps the sequence.
> 
> It also had concerns about concurrent scanners and ptl lock contention,
> but mm->numa_next_scan only admits one per scan period.
> 
> Either way on a rewalk the scan hits pte_protnone() and moves on.
> 

On a second look, there are a few issues bundled in with this, and the
change required to handle the concurrent scan + mode=3 (_NORMAL |
_TIERING) requires a bit more complex of a change to fully resolve.

Will push a v2 after some additional testing - but that said the
existing tests still stand.  As-is, any mode with _TIERING set is very
broken at the moment because of the filtering mechanisms.

~Gregory