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

[Jianyong Wu]

Hi Chenyu,

> -----Original Message-----
> From: Chen, Yu C <yu.c.chen@xxxxxxxxx>
> Sent: Monday, April 13, 2026 4:38 PM
> To: Jianyong Wu <wujianyong@xxxxxxxx>
> Cc: peterz@xxxxxxxxxxxxx; kprateek.nayak@xxxxxxx; mingo@xxxxxxxxxx;
> vincent.guittot@xxxxxxxxxx; juri.lelli@xxxxxxxxxx;
> dietmar.eggemann@xxxxxxx; rostedt@xxxxxxxxxxx; bsegall@xxxxxxxxxx;
> mgorman@xxxxxxx; vschneid@xxxxxxxxxx; vineethr@xxxxxxxxxxxxx;
> hdanton@xxxxxxxx; sshegde@xxxxxxxxxxxxx; jianyong.wu@xxxxxxxxxxx;
> cyy@xxxxxxxxxxxx; tingyin.duan@xxxxxxxxx; vernhao@xxxxxxxxxxx;
> haoxing990@xxxxxxxxx; len.brown@xxxxxxxxx; aubrey.li@xxxxxxxxx;
> zhao1.liu@xxxxxxxxx; adamli@xxxxxxxxxxxxxxxxxxxxxx;
> tim.c.chen@xxxxxxxxxxxxxxx; ziqianlu@xxxxxxxxxxxxx;
> tim.c.chen@xxxxxxxxx; joshdon@xxxxxxxxxx; gavinguo@xxxxxxxxxx;
> qyousef@xxxxxxxxxxx; libchen@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; Huangsj <huangsj@xxxxxxxx>;
> luogengkun2@xxxxxxxxxx
> Subject: Re: [RFC PATCH] sched/fair: dynamically scale the period of cache
> work
> 
> Hi Jianyong,
> 
> On 4/13/2026 3:23 PM, 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.
> >
> > On the other hand, if the preferred node becomes suboptimal, we
> should
> > increase the scan frequency to quickly find a better placement. The
> > scan period is therefore dynamically adjusted.
> >
> > Signed-off-by: Jianyong Wu <wujianyong@xxxxxxxx>
> >
> > ---
> > Hi ChenYu, Tim, Gengkun,
> >
> > I have another approach to address this issue, based on the
> > observation that the scan work can be canceled if the preferred node
> > is stable.This patch merely demonstrates the idea, but still needs
> > more testing to verify its functionality. I'm sending it out early to
> > gather feedback and opinions.
> >
> 
> Thanks for providing this patch.
> 
> >   	if (work->next == work) {
> > @@ -1728,7 +1734,7 @@ static void task_cache_work(struct
> callback_head *work)
> >   	struct task_struct *p = current, *cur;
> >   	unsigned long curr_m_a_occ = 0;
> >   	struct mm_struct *mm = p->mm;
> > -	unsigned long m_a_occ = 0;
> > +	unsigned long m_a_occ = 0, need_scan = 0, now;
> >   	cpumask_var_t cpus;
> >   	u64 t0, scan_cost;
> >
> > @@ -1753,6 +1759,12 @@ static void task_cache_work(struct
> > callback_head *work)
> >
> >   	t0 = sched_clock_cpu(curr_cpu);
> >
> > +	now = jiffies;
> > +	if (time_before(now, READ_ONCE(mm->sc_stat.next_scan)))
> > +		return;
> > +
> 
> I agree that limiting the scan rate would be useful, and your above change
> is actually similar to what NUMA balancing did in task_numa_work(). It
> allows only one thread within the same process to perform the statistics
> calculation, which avoids redundant computation.
> 
> > +	WRITE_ONCE(mm->sc_stat.next_scan, (now +
> mm->sc_stat.scan_period));
> > +
> 
> I suppose the above should be try_cmpxchg()?

Even though the update is not observed by others, it may not be a big problem.
However, using try_cmpxchg may incur more overhead than WRITE_ONCE.
So, I wonder if we can tolerate such a loss of "correctness" for the sake of performance.

> 
> That is to say, with your above change, we have already limited the scan
> ratio for multi-threaded processes significantly. There appears to be no
> need to perform adaptive adjustment of scan_period - the benefit of
> introducing an adaptive scan_period may not offset the overhead of
> frequent writing to the "global" mm->sc_stat.scan_period due to c2c?
> 

If we can increase the scan period, the operations inside the scan work will
not be executed frequently. Thus, there is little overhead from writing to the global variable.
This only occurs when the preferred node is unstable and the scan work runs
frequently. If the preferred node remains stable most of the time, we can still benefit from it.

Thanks
Jianyong
> thanks,
> Chenyu
> 
> 
>