From: preeti@linux.vnet.ibm.com (Preeti U Murthy)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 1/4] sched: extend the usage of cpu_power_orig
Date: Tue, 01 Apr 2014 16:09:36 +0530 [thread overview]
Message-ID: <533A9768.6060006@linux.vnet.ibm.com> (raw)
In-Reply-To: <1396012949-6227-2-git-send-email-vincent.guittot@linaro.org>
Hi Vincent,
On 03/28/2014 06:52 PM, Vincent Guittot wrote:
> cpu_power_orig is only changed for SMT system in order to reflect the lower
> capacity of CPUs. Heterogenous system also have to reflect an original
> capacity that is different from the default value.
There is no parameter 'cpu_power_orig' till your fourth patch right?
Why is this term being used in this patch?
Besides, both parameters power and power_orig are changed for SMT
systems to reflect the lower capacity of the CPUs.Why is there a mention
of only power_orig?
IMO, the subject of the patch is not clearly reflecting the main
intention of the patch. There is nothing done to change the way
cpu_power is used; rather you are changing the way the cpu_power is
being set to be flexible, thus allowing for the right power value to be
set on heterogeneous systems.
'Allow archs to set the cpu_power instead of falling to default value'
or something similar would be more appropriate. What do you think?
Regards
Preeti U Murthy
>
> Create a more generic function arch_scale_cpu_power that can be also used by
> non SMT platform to set cpu_power_orig.
>
> The weak behavior of arch_scale_cpu_power is the previous SMT one in order to
> keep backward compatibility in the use of cpu_power_orig.
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> kernel/sched/fair.c | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 7e9bd0b..ed42061 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5559,6 +5559,20 @@ unsigned long __weak arch_scale_smt_power(struct sched_domain *sd, int cpu)
> return default_scale_smt_power(sd, cpu);
> }
>
> +unsigned long __weak arch_scale_cpu_power(struct sched_domain *sd, int cpu)
> +{
> + unsigned long weight = sd->span_weight;
> +
> + if ((sd->flags & SD_SHARE_CPUPOWER) && weight > 1) {
> + if (sched_feat(ARCH_POWER))
> + return arch_scale_smt_power(sd, cpu);
> + else
> + return default_scale_smt_power(sd, cpu);
> + }
> +
> + return SCHED_POWER_SCALE;
> +}
> +
> static unsigned long scale_rt_power(int cpu)
> {
> struct rq *rq = cpu_rq(cpu);
> @@ -5590,18 +5604,12 @@ static unsigned long scale_rt_power(int cpu)
>
> static void update_cpu_power(struct sched_domain *sd, int cpu)
> {
> - unsigned long weight = sd->span_weight;
> unsigned long power = SCHED_POWER_SCALE;
> struct sched_group *sdg = sd->groups;
>
> - if ((sd->flags & SD_SHARE_CPUPOWER) && weight > 1) {
> - if (sched_feat(ARCH_POWER))
> - power *= arch_scale_smt_power(sd, cpu);
> - else
> - power *= default_scale_smt_power(sd, cpu);
> + power *= arch_scale_cpu_power(sd, cpu);
>
> - power >>= SCHED_POWER_SHIFT;
> - }
> + power >>= SCHED_POWER_SHIFT;
>
> sdg->sgp->power_orig = power;
>
next prev parent reply other threads:[~2014-04-01 10:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 13:22 [RFC 0/4] sched: consolidation of cpu_power Vincent Guittot
2014-03-28 13:22 ` [RFC 1/4] sched: extend the usage of cpu_power_orig Vincent Guittot
2014-04-01 10:39 ` Preeti U Murthy [this message]
2014-04-01 11:20 ` Vincent Guittot
2014-04-03 10:40 ` Preeti U Murthy
2014-03-28 13:22 ` [RFC 2/4] ARM: topology: use new cpu_power interface Vincent Guittot
2014-03-28 13:22 ` [RFC 3/4] sched: fix computed capacity for HMP Vincent Guittot
2014-04-15 17:22 ` Peter Zijlstra
2014-04-16 6:54 ` Vincent Guittot
2014-03-29 2:27 ` [RFC 0/4] sched: consolidation of cpu_power Nicolas Pitre
2014-03-31 7:31 ` Vincent Guittot
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=533A9768.6060006@linux.vnet.ibm.com \
--to=preeti@linux.vnet.ibm.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).