On Wed, Jun 11, 2014 at 11:40 PM, Doug Smythies <dsmyth...@telus.net> wrote: > > > -----Original Message----- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. > Wysocki > Sent: June-11-2014 11:29 > To: Doug Smythies > Cc: Stratos Karafotis; linux...@vger.kernel.org; Linux Kernel Mailing List; > Rafael J. Wysocki; viresh.ku...@linaro.org; dirk.j.brande...@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 <dsmyth...@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.
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
