Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751905AbcCXXsN (ORCPT ); Thu, 24 Mar 2016 19:48:13 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:2777 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbcCXXsL (ORCPT ); Thu, 24 Mar 2016 19:48:11 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Thu, 24 Mar 2016 16:47:04 -0700 Message-ID: <56F47C89.9070201@nvidia.com> Date: Thu, 24 Mar 2016 16:47:21 -0700 From: Sai Gurrappadi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Steve Muckle , Peter Zijlstra , Ingo Molnar CC: , , "Rafael J. Wysocki" , Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Juri Lelli , Patrick Bellasi , Michael Turquette , Subject: Re: [PATCH 2/2] sched/fair: do not call cpufreq hook unless util changed References: <1458606068-7476-1-git-send-email-smuckle@linaro.org> <1458606068-7476-2-git-send-email-smuckle@linaro.org> In-Reply-To: <1458606068-7476-2-git-send-email-smuckle@linaro.org> X-NVConfidentiality: public Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.187.121] X-ClientProxiedBy: HQMAIL108.nvidia.com (172.18.146.13) To HQMAIL101.nvidia.com (172.20.187.10) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2091 Lines: 58 Hi Steve, On 03/21/2016 05:21 PM, Steve Muckle wrote: > There's no reason to call the cpufreq hook if the root cfs_rq > utilization has not been modified. > > Signed-off-by: Steve Muckle > --- > kernel/sched/fair.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index d418deb04049..af58e826cffe 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -2826,20 +2826,21 @@ static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq) > { > struct sched_avg *sa = &cfs_rq->avg; > struct rq *rq = rq_of(cfs_rq); > - int decayed, removed = 0; > + int decayed, removed_load = 0, removed_util = 0; > int cpu = cpu_of(rq); > > if (atomic_long_read(&cfs_rq->removed_load_avg)) { > s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0); > sa->load_avg = max_t(long, sa->load_avg - r, 0); > sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0); > - removed = 1; > + removed_load = 1; > } > > if (atomic_long_read(&cfs_rq->removed_util_avg)) { > long r = atomic_long_xchg(&cfs_rq->removed_util_avg, 0); > sa->util_avg = max_t(long, sa->util_avg - r, 0); > sa->util_sum = max_t(s32, sa->util_sum - r * LOAD_AVG_MAX, 0); > + removed_util = 1; > } > > decayed = __update_load_avg(now, cpu, sa, > @@ -2850,7 +2851,8 @@ static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq) > cfs_rq->load_last_update_time_copy = sa->last_update_time; > #endif > > - if (cpu == smp_processor_id() && &rq->cfs == cfs_rq) { > + if (cpu == smp_processor_id() && &rq->cfs == cfs_rq && > + (decayed || removed_util)) { > unsigned long max = rq->cpu_capacity_orig; Should this filtering instead happen on the governor side? Even if the CFS load itself didn't change, we could have switched from an RT/DL thread to a CFS thread so util would have to be updated from ULONG_MAX to whatever CFS needs right? Also now that CFS enqueue calls cpufreq_update_util, RT/DL requests could potentially get overridden. -Sai