linux-kernel - RE: [PATCH] cpufreq: intel_pstate: Fix rounding of core

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Jun 2014 14:40:02 -0700
From:	"Doug Smythies" <dsmythies@...us.net>
To:	"'Rafael J. Wysocki'" <rafael@...nel.org>
Cc:	"'Stratos Karafotis'" <stratosk@...aphore.gr>,
	<linux-pm@...r.kernel.org>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>,
	"'Rafael J. Wysocki'" <rjw@...ysocki.net>,
	<viresh.kumar@...aro.org>, <dirk.j.brandewie@...el.com>
Subject: RE: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct



-----Original Message-----
From: rjwysocki@...il.com [mailto:rjwysocki@...il.com] On Behalf Of Rafael J. Wysocki
Sent: June-11-2014 11:29
To: Doug Smythies
Cc: Stratos Karafotis; linux-pm@...r.kernel.org; Linux Kernel Mailing List; Rafael J. Wysocki; viresh.kumar@...aro.org; dirk.j.brandewie@...el.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@...us.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/