Re: [Patch v4 02/22] sched/cache: Limit the scan number of CPUs when calculating task occupancy

Luo Gengkun
2026-04-10T10:20:15Z

On 2026/4/10 15:29, Chen, Yu C wrote:
> Hi Gengkun,
>
> On 4/9/2026 9:17 PM, Luo Gengkun wrote:
>>
>>
>> On 2026/4/2 5:52, Tim Chen wrote:
>>> From: Chen Yu <yu.c.chen@intel.com>
>
> [ ... ]
>
>>
>> To address the issue of scanning overhead, there is a more targeted approach: only scanning the CPUs actually accessed by the process, and evicting these CPUs when they remain unaccessed for a specific period of time.
>>
>
> Thanks for the patch. This approach looks quite sensible to me, and
>
> [ ... ]
>
>>
>>          /*
>>           * The update to mm->sc_stat should not be reordered
>> @@ -1582,6 +1584,7 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
>>                  pcpu_sched->runtime += delta_exec;
>>                  rq->cpu_runtime += delta_exec;
>>                  epoch = rq->cpu_epoch;
>> +               cpumask_set_cpu(cpu_of(rq), &mm->sc_stat.visited_cpus);
>
> I would refer a check before writing to avoid c2c overhead:
>     if (!cpumask_test_cpu(cpu_of(rq), &mm->sc_stat.visited_cpus))
>         cpumask_set_cpu(cpu_of(rq), &mm->sc_stat.visited_cpus);
>
>>          }
>>
>>
>>          /*
>> @@ -1724,7 +1727,10 @@ static void task_cache_work(struct callback_head *work)
>>                  return;
>>
>>
>>          scoped_guard (cpus_read_lock) {
>> -               get_scan_cpumasks(cpus, p);
>> +               if (unlikely(llc_epoch_visited_timeout == 0))
>> +                       get_scan_cpumasks(cpus, p);
>> +               else
>> +                       cpumask_and(cpus, cpu_online_mask, &mm-  >sc_stat.visited_cpus);
>>
>
> I believe this patch will bring significant benefits(reduce jitter)
> whenthe thread count is low, since it skips many CPUs. The only concern
> is the frequency of reading and writing the "global" mm->sc_stat.visited_cpus
> from multiple threads. However, if Peter's sbm can be leveraged in the future,
This is a problem, maybe a per-cpu version can help to avoid this problem. I'll
try writing one.
> this  overhead should be further reduced. Anyway, let me run tests on our
> machines to seethe results. Much appreciated!
>
> thanks,
> Chenyu
>
>
>
>