Messages in this thread | | | Date | Thu, 7 Mar 2019 11:59:42 +0000 | From | Quentin Perret <> | Subject | Re: [RFT][Update][PATCH 2/2] cpufreq: intel_pstate: Update max CPU frequency on global turbo changes |
| |
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@arm.com> 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
| |