Re: [PATCH v5 5/7] sched/numa: scan PID-inactive VMAs for promotion

["Gregory Price (Meta)" <gourry@gourry.net>]

On 2026-11-10 15:36 -0500, Gregory Price (Meta) wrote:
> On 2026-11-10 10:04 -0500, Gregory Price (Meta) wrote:
> ... snip ...
> 
> Sashiko report feedback
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -4249,7 +4249,7 @@ static bool vma_needs_placement_scan(struct vm_area_struct *vma)
> >  	 * threads can help scan this vma, force a vma scan.
> >  	 */
> >  	if (READ_ONCE(mm->numa_scan_seq) >
> > -	   (vma->numab_state->prev_scan_seq + get_nr_threads(current)))
> > +	   (vma->numab_state->prev_placement_scan_seq + get_nr_threads(current)))
> >  		return true;
> ... snip ...
> > +		if (placement_scan)
> > +			vma->numab_state->prev_placement_scan_seq = mm->numa_scan_seq;
> 
> Sashiko took issue with these skips, but its reported impact is
> overstated.  It tries to point out a pre-existing condition:
> 
>   prev_scan_seq skips an update on a rare corner condition, but
>   now the same skip applies to prev_placement_scan_seq.
> 
> In modes 1 (placement) and 2 (tiering), the behavior is exactly the
> same as it was.
> 
> In mode 3 (placement + tiering) the result is that the starvation
> counter isn't reset - but everything still works anyway because the
> VMA is still being scanned.
> 
> I can follow up with *another* commit, but it's really low impact.
> Not sure it's worth the churn.
> 

I will refresh this next week and just address it in another commit.

-- 
~Gregory