linux-kernel - Re: [PATCH] cpufreq: conservative: fix requested

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 8 Nov 2013 23:46:06 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Stratos Karafotis <skarafotis@...il.com>
Cc:	Xiaoguang Chen <chenxg@...vell.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xiaoguang Chen <chenxg.marvell@...il.com>
Subject: Re: [PATCH] cpufreq: conservative: fix requested_freq reduction issue

On 8 November 2013 23:13, Stratos Karafotis <skarafotis@...il.com> wrote:
> Please let me rephrase my previous post. In some circumstances (depending
> on freq_step and freq_table values) CPU frequency will never reach to
> policy->max.
>
> For example suppose that (for simplicity values in MHz):
> policy->max = 1000
> policy->cur = 800
> requested_freq = 800
> freq_target = 300
>
> In 'first' iteration, if we return early with this code (because
> requested_freq will be
> 1100):
> if (dbs_info->requested_freq >= policy->max)
>      return;

That's not correct. At this point requested_freq would have been
800 only, and would have increased after this instruction to 1100.
So, in the first transition we will go to max freq, but not from the
second.

Though this piece of code is more simplified by the new solution
I gave.

> CPU freq will never go over 800MHz.
>
> I think the current code works correctly.
> - The requested freq will go to 1100 in first iteration.
> - __cpufreq_driver_target will change CPU freq to 1000
> - dbs_cpufreq_notifier will adjust the requested_freq to 1000

> So, I think there is no need for an extra check because of
> dbs_cpufreq_notifier code.

Now with the new code in place we are correcting requested_freq
in cs_check_cpu(), then why do we need dbs_cpufreq_notifier()?

What do you think?
--
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/