[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20160315214354.GL6344@twins.programming.kicks-ass.net>
Date: Tue, 15 Mar 2016 22:43:54 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Michael Turquette <mturquette@...libre.com>
Cc: rjw@...ysocki.net, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, Juri.Lelli@....com,
steve.muckle@...aro.org, morten.rasmussen@....com,
dietmar.eggemann@....com, vincent.guittot@...aro.org,
Michael Turquette <mturquette+renesas@...libre.com>
Subject: Re: [PATCH 2/8] sched/fair: add margin to utilization update
On Tue, Mar 15, 2016 at 02:28:48PM -0700, Michael Turquette wrote:
> Quoting Peter Zijlstra (2016-03-15 14:16:14)
> > On Sun, Mar 13, 2016 at 10:22:06PM -0700, Michael Turquette wrote:
> > > @@ -2840,6 +2853,8 @@ static inline void update_load_avg(struct sched_entity *se, int update_tg)
> > >
> > > if (cpu == smp_processor_id() && &rq->cfs == cfs_rq) {
> > > unsigned long max = rq->cpu_capacity_orig;
> > > + unsigned long cap = cfs_rq->avg.util_avg *
> > > + cfs_capacity_margin / max;
> > >
> > > /*
> > > * There are a few boundary cases this might miss but it should
> > > @@ -2852,8 +2867,7 @@ static inline void update_load_avg(struct sched_entity *se, int update_tg)
> > > * thread is a different class (!fair), nor will the utilization
> > > * number include things like RT tasks.
> > > */
> > > - cpufreq_update_util(rq_clock(rq),
> > > - min(cfs_rq->avg.util_avg, max), max);
> > > + cpufreq_update_util(rq_clock(rq), min(cap, max), max);
> > > }
> > > }
> >
> > I really don't see why that is here, and not inside whatever uses
> > cpufreq_update_util().
>
> Because I want schedutil to be dumb and not implement any policy of it's
> own. The idea is for the scheduler to select frequency after all.
>
> I want to avoid a weird hybrid solution where we try to be smart about
> selecting the right capacity/frequency in fair.c (e.g. Steve and Juri's
> patches to fair.c from the sched-freq-v7 series), but then have an
> additional layer of "smarts" massaging those values further in the
> cpufreq governor.
So the problem here is that you add an unconditional division, even if
cpufreq_update_util() then decides to not do anything with it.
Please, these are scheduler paths, do not add (fancy) instructions if
you don't absolutely have to.
Powered by blists - more mailing lists