From: Douglas Raillard <douglas.raillard@arm.com>
To: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
mingo@redhat.com, peterz@infradead.org, quentin.perret@arm.com,
dietmar.eggemann@arm.com, rjw@rjwysocki.net,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [RFC PATCH 1/7] PM: Introduce em_pd_get_higher_freq()
Date: Thu, 16 May 2019 14:06:08 +0100 [thread overview]
Message-ID: <046bfab7-bf28-bbfe-2bff-09881d537fb1@arm.com> (raw)
In-Reply-To: <20190516124200.opxczohjelhvrzmo@e110439-lin>
Hi Patrick,
On 5/16/19 1:42 PM, Patrick Bellasi wrote:
> On 08-May 18:42, douglas.raillard@arm.com wrote:
>> From: Douglas RAILLARD <douglas.raillard@arm.com>
>>
>> em_pd_get_higher_freq() returns a frequency greater or equal to the
>> provided one while taking into account a given cost margin. It also
>> skips inefficient OPPs that have a higher cost than another one with a
>> higher frequency.
>
> It's worth to add a small description and definition of what we mean by
> "OPP efficiency". Despite being just an RFC, it could help to better
> understand what we are after.
Right, here efficiency=capacity/power.
>
> [...]
>
>> +/** + * em_pd_get_higher_freq() - Get the highest frequency that
>> does not exceed the
>> + * given cost margin compared to min_freq
>> + * @pd : performance domain for which this must be done
>> + * @min_freq : minimum frequency to return
>> + * @cost_margin : allowed margin compared to min_freq, as a per-1024 value.
> ^^^^^^^^
> here...
>
>> + *
>> + * Return: the chosen frequency, guaranteed to be at least as high as min_freq.
>> + */
>> +static inline unsigned long em_pd_get_higher_freq(struct em_perf_domain *pd,
>> + unsigned long min_freq, unsigned long cost_margin)
>> +{
>> + unsigned long max_cost = 0;
>> + struct em_cap_state *cs;
>> + int i;
>> +
>> + if (!pd)
>> + return min_freq;
>> +
>> + /* Compute the maximum allowed cost */
>> + for (i = 0; i < pd->nr_cap_states; i++) {
>> + cs = &pd->table[i];
>> + if (cs->frequency >= min_freq) {
>> + max_cost = cs->cost + (cs->cost * cost_margin) / 1024;
> ^^^^
> ... end here we should probably better use SCHED_CAPACITY_SCALE
> instead of hard-coding in values, isn't it?
"cs->cost*cost_margin/1024" is not a capacity, it's a cost as defined here:
https://elixir.bootlin.com/linux/latest/source/include/linux/energy_model.h#L17
Actually, it's in milliwatts, but it's not better the better way to look at
it to understand it IMHO.
The margin is expressed as a "per-1024" value just like we use percents'
in everyday life, so it has no unit. If we want to avoid hard-coded values
here, I can introduce an ENERGY_COST_MARGIN_SCALE macro.
>> + break;
>> + }
>> + }
>> +
>
> [...]
>
> Best,
> Patrick
Thanks,
Douglas
next prev parent reply other threads:[~2019-05-16 13:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-08 17:42 [RFC PATCH 0/7] sched/cpufreq: Make schedutil energy aware douglas.raillard
2019-05-08 17:42 ` [RFC PATCH 1/7] PM: Introduce em_pd_get_higher_freq() douglas.raillard
2019-05-16 12:42 ` Patrick Bellasi
2019-05-16 13:01 ` Quentin Perret
2019-05-16 13:22 ` Patrick Bellasi
2019-06-19 16:08 ` Douglas Raillard
2019-06-20 13:04 ` Patrick Bellasi
2019-06-21 10:17 ` Quentin Perret
2019-06-21 10:22 ` Quentin Perret
2019-05-16 13:06 ` Douglas Raillard [this message]
2019-05-08 17:42 ` [RFC PATCH 2/7] sched/cpufreq: Attach perf domain to sugov policy douglas.raillard
2019-05-08 17:42 ` [RFC PATCH 3/7] sched/cpufreq: Hook em_pd_get_higher_power() into get_next_freq() douglas.raillard
2019-05-08 17:42 ` [RFC PATCH 4/7] sched/cpufreq: Move up sugov_cpu_is_busy() douglas.raillard
2019-05-08 17:42 ` [RFC PATCH 5/7] sched/cpufreq: sugov_cpu_is_busy for shared policy douglas.raillard
2019-05-08 17:43 ` [RFC PATCH 6/7] sched/cpufreq: Improve sugov_cpu_is_busy accuracy douglas.raillard
2019-05-16 12:55 ` Patrick Bellasi
2019-06-19 16:19 ` Douglas Raillard
2019-06-20 11:05 ` Patrick Bellasi
2019-05-08 17:43 ` [RFC PATCH 7/7] sched/cpufreq: Boost schedutil frequency ramp up douglas.raillard
2019-05-13 7:12 ` [RFC PATCH 0/7] sched/cpufreq: Make schedutil energy aware Viresh Kumar
2019-05-13 13:52 ` Douglas Raillard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=046bfab7-bf28-bbfe-2bff-09881d537fb1@arm.com \
--to=douglas.raillard@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=quentin.perret@arm.com \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.