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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190304191059.mzwid3udqwtzejww@queper01-lin>
Date:   Mon, 4 Mar 2019 19:11:01 +0000
From:   Quentin Perret <quentin.perret@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Wang, Vincent (王争) 
        <Vincent.Wang@...soc.com>,
        Zhang, Chunyan (张春艳) 
        <Chunyan.Zhang@...soc.com>, Ingo Molnar <mingo@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: 答复: [PATCH V4] sched/cpufreq: initialize iowait_boost_max and
 iowait_boost with cpu capacity

On Monday 04 Mar 2019 at 19:47:08 (+0100), Peter Zijlstra wrote:
> On Mon, Mar 04, 2019 at 05:50:32PM +0000, Quentin Perret wrote:
> > On Monday 04 Mar 2019 at 18:40:28 (+0100), Peter Zijlstra wrote:
> > > > Perhaps you could keep the 'util' and 'max' pointers in
> > > > sugov_iowait_apply() and overwrite them like before, but in the
> > > > SCHED_CAPACITY_SCALE scale as you suggest ?
> > > 
> > > Urgh; but then we're back to having that boostrap problem.
> > 
> > Hmm, I don't understand :/
> 
> Yeah, I seen to have reading comprehension issues today. Ignore that.
> 
> > > Now; at this time; @max is in fact scale_cpu_capacity, so can't we
> > > change this:
> > > 
> > > -       /*
> > > -        * Apply the current boost value: a CPU is boosted only if its current
> > > -        * utilization is smaller then the current IO boost level.
> > > -        */
> > > -       boost_util = sg_cpu->iowait_boost;
> > > -       boost_max = sg_cpu->iowait_boost_max;
> > 
> > I was basically suggesting to do 'boost_max = 1024;' here and you
> > should be good with you way of computing 'min' no ?
> 
> Right, but then we keep having to retain those two mults.
> 
> > > -       if (*util * boost_max < *max * boost_util) {
> > > -               *util = boost_util;
> > > -               *max = boost_max;
> > > -       }
> > > +       sg_cpu->iowait_boost_pending = false;
> > > +
> > > +       return min(max(util, sg_cpu->iowait_boost), max);
> > > }
> > > 
> > > to something like:
> > > 
> > > 	/*
> > > 	 * @util is already in capacity scale, convert iowait_boost
> > > 	 * into the same scale so we can compare.
> > > 	 */
> > > 	boost = (sg_cpu->iowait_boost * max) >> SCHED_CAPACITY_SHIFT;
> > > 	util = max(boost, util);
> > > 	return min(util, max);
> > > 
> > 
> > But this should work too, I think.
> 
> While that is only a single mult.

Yes, and that's also easier to understand (IMO) because all the
requests going to get_next_freq() are in the scale_cpu_capacity range,
which keeps things consistent regardless of the iowait stuff.

So yeah, that works for me.

Thanks,
Quentin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ