[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180411092756.GK14248@e110439-lin>
Date: Wed, 11 Apr 2018 10:27:56 +0100
From: Patrick Bellasi <patrick.bellasi@....com>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
"open list:THERMAL" <linux-pm@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Viresh Kumar <viresh.kumar@...aro.org>,
Juri Lelli <juri.lelli@...hat.com>,
Joel Fernandes <joelaf@...gle.com>,
Steve Muckle <smuckle@...gle.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Morten Rasmussen <morten.rasmussen@....com>
Subject: Re: [PATCH] sched/fair: schedutil: update only with all info
available
On 11-Apr 09:57, Vincent Guittot wrote:
> On 6 April 2018 at 19:28, Patrick Bellasi <patrick.bellasi@....com> wrote:
>
> > }
> > @@ -5454,8 +5441,11 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
> > update_cfs_group(se);
> > }
> >
> > - if (!se)
> > + /* The task is no more visible from the root cfs_rq */
> > + if (!se) {
> > sub_nr_running(rq, 1);
> > + cpufreq_update_util(rq, 0);
>
> call to cpufreq_update_util() should be done after util_est_dequeue()
Yeah... good point, looks like I should have notice it :)
That's another compelling example why updating schedutil as a side
effect of update_load_avg does not allow to easily track when it's the
best time to trigger an update.
UtilEst is now a factor which could impact on OPP selection for CFS
tasks, and thus we should update at the really end of the function.
> > + }
> >
> > util_est_dequeue(&rq->cfs, p, task_sleep);
> > hrtick_update(rq);
--
#include <best/regards.h>
Patrick Bellasi
Powered by blists - more mailing lists