Re: [RFT][Update][PATCH 2/2] cpufreq: intel_pstate: Update max CPU frequency on global turbo changes

[Quentin Perret]

On Thursday 07 Mar 2019 at 12:25:10 (+0100), Rafael J. Wysocki wrote:
> On Thu, Mar 7, 2019 at 12:03 PM Quentin Perret <quentin.perret@xxxxxxx> wrote:
> >
> > Hi Rafael,
> >
> > On Wednesday 06 Mar 2019 at 11:05:47 (+0100), Rafael J. Wysocki wrote:
> > > Please recall that the iowait boosting algo was different to start
> > > with, though: it jumped to the max right away and then backed off.
> > > That turned out to be overly aggressive in general and led to some
> > > undesired "jittery" behavior, which is why it was changed.
> > >
> > > Thus it looks like the platforms on which it still jumps to the max
> > > right away may actually benefit from changing it to more steps. :-)
> >
> > On the energy side of things at least ... ;-)
> >
> > > In turn, the platforms where it takes more than 3 steps for the boost
> > > to get to the max would get a slight performance improvement from this
> > > changes and I'm not sure why that could be bad.
> >
> > For energy possibly ? IIUC this thread:
> >
> >     https://patchwork.kernel.org/patch/9735885/
> >
> > the original intent of the ramp thing for the iowait boost was to reduce
> > power consumption.
> >
> > > Moreover, it didn't depend on the min originally, just on the max and
> > > just because I wanted the number of backoff steps needed to go back
> > > down to zero to be independent of the platform IIRC.  The dependency
> > > on the min is sort of artificial here and leads to arbitrary
> > > differences in behavior between different platforms which isn't
> > > particularly fortunate.
> >
> > It's a question of perspective I would say. Right now you can say the
> > behaviour is somewhat coherent across platforms: getting an IOWAIT boost
> > means you'll run twice as fast regardless of your board. With the '128
> > approach', you may or may not run faster, depending on your set of OPPs.
> >
> > Also on recent big little SoCs, the capacity ratio can be pretty high.
> > You can get little CPUs with 300 of capacity or so. The arbitrary 128
> > thing is basically gonna go near max freq in one step, although the CPUs
> > actually 20 available OPPs or so. And I guess that's a shame.
> 
> OK, you seem to be arguing that on some platforms there is a little
> difference between 128 and 1024 in terms of power, while there may be
> a lot of difference between, say, 64 and 128.

Well, in fact what I was saying here is wrong. As Peter said in another
email, we'll scale the boost to the CPU's cap, so even on little CPUs it
would take 4 steps to go to max ... So the problem I was trying to
highlight here simply doesn't exist.

So yes, please ignore that point :/

> I can buy that, but then it also makes sense to boost quickly enough,
> so maybe it could start at the min and jump from there to 256 right
> away in the first step?
> 
> > For these reasons, I feel like it's not completely idiotic to have a
> > platform-dependent starting point, although arguably min_freq might not
> > always be the best choice.
> >
> > > With all of that in mind, I would go right away to making the boost
> > > independent of min and max (the final number of steps to reach the max
> > > is TBD in practice, but 3 looks like a good enough compromise to me).
> >
> > Perhaps the energy model could help find a good starting point, and a
> > good number of steps ?
> >
> > FWIW there should be a slot at OSPM to discuss how sugov could be made
> > smarter using the EM :-).
> 
> Well, if you can make a case for that. :-)

:-)

Thanks,
Quentin