RE: [RFC PATCH] sched/fair: dynamically scale the period of cache work

[Jianyong Wu]

Hi Tim,

> On Mon, 2026-04-13 at 15:23 +0800, Jianyong Wu wrote:
> > When a preferred LLC is selected and remains stable, task_cache_work
> > does not need to run frequently. Because it scans all system CPUs for
> > computation, high-frequency execution hurts performance. We thus
> > reduce the scan rate in such cases.
> >
> 
> Thanks for your patch proposal.
> 
> > On the other hand, if the preferred node becomes suboptimal, we
> should
> 
> You mean preferred LLC right? preferred node is from NUMA balancing.

Sorry for the misunderstanding. Yes, I meant the preferred LLC here.
> 
> 
> > @@ -1822,9 +1835,35 @@ static void task_cache_work(struct
> callback_head *work)
> >  		 * 3. 2X is chosen based on test results, as it delivers
> >  		 *    the optimal performance gain so far.
> >  		 */
> > -		mm->sc_stat.cpu = m_a_cpu;
> > +		if (m_a_occ > (2 * curr_m_a_occ))
> > +			mm->sc_stat.cpu = m_a_cpu;
> > +
> > +		if (!mm->sc_stat.last_reset_tick)
> > +			mm->sc_stat.last_reset_tick = now;
> > +
> > +		/* Change scan_period when preferred LLC changed */
> > +		if (((mm->sc_stat.cpu != -1) && (m_a_cpu != -1)
> > +			&& (llc_id(mm->sc_stat.cpu) != llc_id(m_a_cpu)))
> > +			|| need_scan) {
> > +			if (!need_scan)
> > +				need_scan = 1;
> > +
> > +			WRITE_ONCE(mm->sc_stat.scan_period,
> > +				max(mm->sc_stat.scan_period >> 1,
> llc_scan_period_min));
> > +			WRITE_ONCE(mm->sc_stat.last_reset_tick, now);
> > +               }
> > +	}
> > +
> > +	if ((now - READ_ONCE(mm->sc_stat.last_reset_tick) >
> llc_scan_period_threshold)
> > +		&& !need_scan) {
> > +		WRITE_ONCE(mm->sc_stat.scan_period,
> min(mm->sc_stat.scan_period << 1,
> > +			llc_scan_period_max));
> 
> I think that llc_scan_period_max should be the same as
> llc_epoch_affinity_timeout.
> We should not increase the scan period beyond that as that's the time
> scale where we consider cache data relevant.

Sounds reasonable. I'll run some tests to verify if this is sufficient.

Thanks
Jianyong
> 
> Tim
> 
>