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

[Jianyong Wu]

Hi Chenyu,

 
> try_cmpxchg is triggered not very frequently(10 ms) so the overhead might
> not be that high? try_cmpxchg "strictly" avoid two threads entering the
> same loop, and it seems that in the end of task_cache_work() there is a
> update_avg_scale()
> which involves
> u64 *avg += xxx
> which is not atomic so maybe try_cmpxchg could help with that?
> 
Ok, looks like try_cmpxchg has little performance overhead. I'll use it in the next version.

> >>
> >> 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.
> >
> 
> I see. BTW, why mm->sc_stat.need_scan is needed? With sc_stat.next_scan
> and sc_stat.scan_period, we should be able to adjust the timeout.
> 
> Is it because you want other condition to shrink the scan_period?
> Like below:
> +	if (to_pref && ret == mig_forbid)
> +		mm->sc_stat.need_scan = 1;
> 
Yes, here I intend to shorten the scan period once the current preferred LLC may be no longer suitable for the task.

Thanks
Jianyong
> thanks,
> Chenyu