lkml.org 
[lkml]   [2014]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct
    Date


    -----Original Message-----
    From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of Rafael J. Wysocki
    Sent: June-11-2014 11:29
    To: Doug Smythies
    Cc: Stratos Karafotis; linux-pm@vger.kernel.org; Linux Kernel Mailing List; Rafael J. Wysocki; viresh.kumar@linaro.org; dirk.j.brandewie@intel.com
    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@telus.net> 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.

    ... Doug


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

    \
     
     \ /
      Last update: 2014-06-12 00:01    [W:3.309 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site