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

[Rafael J. Wysocki]

On Wed, Jun 11, 2014 at 11:40 PM, Doug Smythies <dsmythies@xxxxxxxxx> wrote:
>
>
> -----Original Message-----
> From: rjwysocki@xxxxxxxxx [mailto:rjwysocki@xxxxxxxxx] On Behalf Of Rafael J. Wysocki
> Sent: June-11-2014 11:29
> To: Doug Smythies
> Cc: Stratos Karafotis; linux-pm@xxxxxxxxxxxxxxx; Linux Kernel Mailing List; Rafael J. Wysocki; viresh.kumar@xxxxxxxxxx; dirk.j.brandewie@xxxxxxxxx
> Subject: Re: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct
>
> On 2014.06.11 11:29 Rafael J. Wysocki wrote:
>> On Wed, Jun 11, 2014 at 5:02 PM, Doug Smythies <dsmythies@xxxxxxxxx> wrote:
>>> On 2104.06.11 07:08 Stratos Karafotis wrote:
>>>> 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.
>>>
>>>> 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.
>
>> Well, can you please do it if that's not a problem?
>
> Yes, of course, but it is a matter of priorities. All I meant by the above comment was that we might be able to forget about the remainder and just do a mindless divide, but leaving it as it is now does no harm in the meantime.
>
> Myself, I consider the issue of excessive deferred timer times to be a much higher priority (see my on-list e-mail from Monday). Correct me if I am wrong.
> Even without the "excessive" part, and for a 250 Hz kernel, the current kick in point can be hit routinely, unduly biasing the CPU frequency downwards.
> A random example (250 Hz kernel): 23% load at 25 Hertz load / sleep frequency for 300 total seconds.
>
> Duration histrogram:
>
> Occurrences duration (seconds)
>      16 0.044
>      39 0.024
>      45 0.028
>      46 0.016
>      48 0.032
>      61 0.036
>     166 0.012
>     198 0.020
>    7166 0.040
>
> Where you can see that the majority of the time the duration is such that the code will force the CPU frequency downwards. It runs at minimum pstate instead of maximum pstate where it should be.

I see.

What would you suggest to do to address this problem, then?

Rafael
--
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/