> static inline int32_t intel_pstate_get_scaled_busy(struct cpudata *cpu)
> {
> - int32_t core_busy, max_pstate, current_pstate;
> + int32_t core_busy, max_pstate, current_pstate, sample_ratio;
> + u32 duration_us;
> + u32 sample_time;
>
> core_busy = cpu->sample.core_pct_busy;
> max_pstate = int_tofp(cpu->pstate.max_pstate);
> current_pstate = int_tofp(cpu->pstate.current_pstate);
> core_busy = mul_fp(core_busy, div_fp(max_pstate, current_pstate));
> +
> + sample_time = (pid_params.sample_rate_ms * USEC_PER_MSEC);
> + duration_us = (u32) ktime_us_delta(cpu->sample.time,
> + cpu->last_sample_time);
> + if (duration_us > sample_time * 3) {
> + sample_ratio = div_fp(int_tofp(sample_time),
> + int_tofp(duration_us));
> + core_busy = mul_fp(core_busy, sample_ratio);
> + }
> +
> return core_busy;
> }
Hi Dirk,
I am afraid I need to question again since you did not address my concern.
So generally, this new patch will factor (sample_rate / duration) in
(last_freq / last_request) if duration > 3*sample_time.
This sample_rate / duration thing looks random. And otherwise it is still
effectively performance governor behavior if what I reasoned before is right.
So my opinion is, the C0 tracking is not the (true) root cause to perf regression.
But if you really need this patch as a temp workaround, it is ok.
Thanks,
Yuyang
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html