Re: Performance regression in v3.14

[Yuyang Du]

> I tried applying your (rejected) patch "intel_pstate: Remove C0
> tracking" posted here:
> 
> 	https://lkml.org/lkml/2014/5/8/574
> 
> to v3.14.4 and it fixes the problem as expected.
> 
> So we have a commit fcb6a15c2e7e ("intel_pstate: Take core C0 time into
> account for core busy calculation") that went into v3.14-rc2 (and was
> even marked for *stable*) that first broke Greg KH's system:
> 
> 	https://lkml.org/lkml/2014/2/19/626
> 
> That was apparently fixed by e66c17683746 ("intel_pstate: Change
> busy calculation to use fixed point math."), but still left v3.14
> basically unusable for lower-intensity workloads such as my
> bash-completion example and other reported regressions:
> 
> 	https://bugzilla.kernel.org/show_bug.cgi?id=75121
> 
> Sure there may be issues with v3.13 not hitting the lowest frequencies
> but at least the system was *usable*.
> 
> In my opinion there's really no other option than to restore the 3.13
> behaviour by effectively reverting fcb6a15c2e7e ("intel_pstate: Take
> core C0 time into account for core busy calculation") until you have
> figured out a way to take C0 into account without breaking things too
> badly.

Hi all,

My posts before and now are only relevant to why C0 tracking can't be
removed. Maybe I need to elaborate on it a little bit more.

In a nutshell, without C0 tracking, the intel_pstate is effectively performance
governor in terms of frequency control. Why?

Without C0 trakcing, the machinery of the freq control is as I formed:

last_freq_average / last_requested_freq ==> setpoint

which can be virtually formed into:

last_freq_average / last_requested_freq * last_C0_pct ==> setpoint * last_C0_pct

which said, the control machinery will increase the freuqency at ANY frequency at
ANY C0_pct (which is the CPU utilization), since setpoint is less then 100
percent. And a few iterations later, we will reach max (possible) frequency,
then we are effectively performance governor (highest frequency all the time).

So, sure, without C0 tracking, the performance issues should be fixed. But
let's simply set highest frequency, that should be better.

It is your decision whether we should remove C0 tracking as a no-other option fix
right now. I am ok either way.

Thanks,
Yuyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/