On 2019.02.05 04:04 Rafael J. Wysocki wrote:
> On Friday, February 1, 2019 5:54:37 PM CET Doug Smythies wrote:
>> On 2019.01.30 16:05 Rafael J. Wysocki wrote:
>> 
>>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>>
>>> The current iowait boosting mechanism in intel_pstate_update_util()
>>> is quite aggressive, as it goes to the maximum P-state right away,
>>> and may cause excessive amounts of energy to be used, which is not
>>> desirable and arguably isn't necessary too.
>>>
>>> Follow commit a5a0809bc58e ("cpufreq: schedutil: Make iowait boost
>>> more energy efficient") that reworked the analogous iowait boost
>>> mechanism in the schedutil governor and make the iowait boosting
>>> in intel_pstate_update_util() work along the same lines.
>>> 
>>> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>> ---
>>>  drivers/cpufreq/intel_pstate.c |   46 
>>> +++++++++++++++++++++++++----------------
>>>  1 file changed, 29 insertions(+), 17 deletions(-)
>>>
>>> Index: linux-pm/drivers/cpufreq/intel_pstate.c
>>> ===================================================================
>>> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
>>> +++ linux-pm/drivers/cpufreq/intel_pstate.c
>>> @@ -50,6 +50,8 @@
>>>  #define int_tofp(X) ((int64_t)(X) << FRAC_BITS)
>>>  #define fp_toint(X) ((X) >> FRAC_BITS)
>>> 
>>> +#define ONE_EIGHTH_FP ((int64_t)1 << (FRAC_BITS - 3))
>>> +
>>>  #define EXT_BITS 6
>>>  #define EXT_FRAC_BITS (EXT_BITS + FRAC_BITS)
>>>  #define fp_ext_toint(X) ((X) >> EXT_FRAC_BITS)
>>> @@ -1678,17 +1680,14 @@ static inline int32_t get_avg_pstate(str
>>>  static inline int32_t get_target_pstate(struct cpudata *cpu)
>>>  {
>>>     struct sample *sample = &cpu->sample;
>>> -   int32_t busy_frac, boost;
>>> +   int32_t busy_frac;
>>>     int target, avg_pstate;
>>> 
>>>     busy_frac = div_fp(sample->mperf << cpu->aperf_mperf_shift,
>>>                        sample->tsc);
>>> 
>>> -   boost = cpu->iowait_boost;
>>> -   cpu->iowait_boost >>= 1;
>>> -
>>> -   if (busy_frac < boost)
>>> -           busy_frac = boost;
>>> +   if (busy_frac < cpu->iowait_boost)
>>> +           busy_frac = cpu->iowait_boost;
>>> 
>>>     sample->busy_scaled = busy_frac * 100;
>>> 
>>> @@ -1767,22 +1766,35 @@ static void intel_pstate_update_util(str
>>>     if (smp_processor_id() != cpu->cpu)
>>>             return;
>>>
>>> +   delta_ns = time - cpu->last_update;
>>>     if (flags & SCHED_CPUFREQ_IOWAIT) {
>>> -           cpu->iowait_boost = int_tofp(1);
>>> -           cpu->last_update = time;
>>> -           /*
>>> -            * The last time the busy was 100% so P-state was max anyway
>>> -            * so avoid overhead of computation.
>>> -            */
>>> -           if (fp_toint(cpu->sample.busy_scaled) == 100)
>>> -                   return;
>>> -
>>> -           goto set_pstate;
>>> +           /* Start over if the CPU may have been idle. */
>>> +           if (delta_ns > TICK_NSEC) {
>>> +                   cpu->iowait_boost = ONE_EIGHTH_FP;
>>> +           } else if (cpu->iowait_boost) {
>>> +                   cpu->iowait_boost <<= 1;
>>> +                   if (cpu->iowait_boost >= int_tofp(1)) {
>>> +                           cpu->iowait_boost = int_tofp(1);
>>> +                           cpu->last_update = time;
>>> +                           /*
>>> +                            * The last time the busy was 100% so P-state
>>> +                            * was max anyway, so avoid the overhead of
>>> +                            * computation.
>>> +                            */
>>> +                           if (fp_toint(cpu->sample.busy_scaled) == 100)
>>> +                                   return;
>> 
>> Hi Rafael,
>> 
>> By exiting here, the trace, if enabled, is also bypassed.
>> We want the trace sample.
>
> Fair enough, but the return is there regardless of this patch.
>
> Maybe it should be fixed separately?

O.K.

>> Also, there is a generic:
>> "If the target ptstate is the same as before, then don't set it"
>> later on.
>> Suggest to delete this test and exit condition. (I see that this early
>> exit was done before also.)
>
> Well, exactly.
>
> It is not unreasonable to boost the frequency right away for an IO-waiter
> without waiting for the next sample time IMO.

I agree, but am just saying that it should include a trace sample, otherwise
it is difficult to understand what happened.

By the way, I forgot to mention before, I tried the patch and it does prevent
CPU frequency spikes to maximum every few seconds in a very idle system.

... Doug


Reply via email to