On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi <[email protected]> wrote: > Currently the utilization of the FAIR class is collected before locking > the policy. Although that should not be a big issue for most cases, we > also don't really know how much latency there can be between the > utilization reading and its usage. > > Let's get the FAIR utilization right before its usage to be better in > sync with the current status of a CPU. > > Signed-off-by: Patrick Bellasi <[email protected]> > Cc: Ingo Molnar <[email protected]> > Cc: Peter Zijlstra <[email protected]> > Cc: Rafael J. Wysocki <[email protected]> > Cc: Viresh Kumar <[email protected]> > Cc: [email protected] > Cc: [email protected] > --- > kernel/sched/cpufreq_schedutil.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/kernel/sched/cpufreq_schedutil.c > b/kernel/sched/cpufreq_schedutil.c > index 98704d8..df433f1 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -308,10 +308,9 @@ static void sugov_update_shared(struct update_util_data > *hook, u64 time, > if (unlikely(current == sg_policy->thread)) > return; > > - sugov_get_util(&util, &max); > - > raw_spin_lock(&sg_policy->update_lock); > > + sugov_get_util(&util, &max); > sg_cpu->util = util; > sg_cpu->max = max;
Is your concern that there will we spinlock contention before calling sugov_get_util? If that's the case, with your patch it seems to me such contention (and hence spinning) itself could cause the utilization to be inflated - thus calling sugov_get_util after acquiring the lock will not be as accurate as before. In that case it seems to me its better to let sugov_get_util be called before acquiring the lock (as before). thanks, -Joel
