linux-kernel - Re: [RFCv5 PATCH 40/46] sched/cpufreq_sched: compute freq_new based on capacity_orig

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] [day] [month] [year] [list]

Message-ID: <561D5FE9.2050503@linaro.org>
Date:	Tue, 13 Oct 2015 12:47:53 -0700
From:	Steve Muckle <steve.muckle@...aro.org>
To:	Juri Lelli <juri.lelli@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	Michael Turquette <mturquette@...libre.com>
Cc:	Morten Rasmussen <Morten.Rasmussen@....com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
	Dietmar Eggemann <Dietmar.Eggemann@....com>,
	"yuyang.du@...el.com" <yuyang.du@...el.com>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"sgurrappadi@...dia.com" <sgurrappadi@...dia.com>,
	"pang.xunlei@....com.cn" <pang.xunlei@....com.cn>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [RFCv5 PATCH 40/46] sched/cpufreq_sched: compute freq_new based
 on capacity_orig_of()

On 08/17/2015 05:19 AM, Juri Lelli wrote:
>> Nah, just maybe: (capacity << SCHED_CAPACITY_SHIFT) / capacity_orig_of()
>> > such that you don't have to export that knowledge to this thing.
>> > 
> Oh, right. I guess we can just go with something like:
> 
>  req_cap = get_cpu_usage(cpu) * capacity_margin / capacity_orig_of(cpu);
> 
> on fair.c side and switch back to
> 
>  freq_new = capacity * policy->max >> SCHED_CAPACITY_SHIFT;
> 
> on cpufreq_sched.c side. That saves us exporting capacity_orig_of().

Another good reason to make this change - I believe the current code
will not support a cpufreq policy covering CPUs of different types (such
as a b.L system in a single frequency domain).

The max requested capacity is calculated using the absolute/global
capacity values requested from each CPU. A small CPU needing a higher
OPP may get ignored because of a request from a big CPU for a lower OPP,
because the big CPU @ lower OPP shows up as the max capacity request.
--
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/