lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ