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]

Message-ID: <5398BA0B.7070903@semaphore.gr>
Date:	Wed, 11 Jun 2014 23:20:27 +0300
From:	Stratos Karafotis <stratosk@...aphore.gr>
To:	Doug Smythies <dsmythies@...us.net>
CC:	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	rjw@...ysocki.net, viresh.kumar@...aro.org,
	dirk.j.brandewie@...el.com
Subject: Re: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct

On 11/06/2014 06:02 μμ, Doug Smythies 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.
> 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


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