Thread (18 messages) 18 messages, 5 authors, 2014-06-13

Re: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct

From: Stratos Karafotis <hidden>
Date: 2014-06-11 20:20:32
Also in: lkml

On 11/06/2014 06:02 μμ, Doug Smythies wrote:
On 2104.06.11 07:08 Stratos Karafotis wrote:
quoted
On 11/06/2014 04:41 μμ, Doug Smythies wrote:

No.

The intent was only ever to round properly the pseudo floating point result of the divide.
It was much more important (ugh, well 4 times more) when FRACBITS was still 6, which also got changed to 8 in a recent patch.
Are you sure?

Yes.
quoted
This rounding was very recently added.
As far as I can understand, I don't see the meaning of this rounding, as is.
Even if FRAC_BITS was 6, I think it would have almost no improvement in
calculations.
Note: I had not seen this e-mail when I wrote a few minutes ago:

You may be correct.
If Dirk agrees, I will re-analyse the entire driver for rounding effects soon.
When FRACBITS was 6 there were subtle cases where the driver would get stuck, and not make a final pstate change, with the default PID gains.
Other things have changed, and the analysis needs to be re-done.
Could you please elaborate a little bit more what we need these 2 lines below?

        if ((rem << 1) >= int_tofp(sample->mperf))
                core_pct += 1;

Because nothing is mentioned for them in commit's changelog.
Do we need to round core_pct or not?
Because if we try to round it, I think this patch should work.

Thanks,
Stratos

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help