linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: vincent.guittot@linaro.org (Vincent Guittot)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 4/4] sched: cpu_power: enable ARCH_POWER
Date: Wed, 13 Jun 2012 15:50:43 +0200	[thread overview]
Message-ID: <CAKfTPtAbmLy5hR-W7RMQpn1cf1jkirv0oNtS_h4dmPYx5gTm1w@mail.gmail.com> (raw)
In-Reply-To: <1339594110.8980.38.camel@twins>

On 13 June 2012 15:28, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2012-06-13 at 15:20 +0200, Vincent Guittot wrote:
>>
>> In v3.4, x86 hasn't got any specific declaration for
>> arch_scale_freq_power so it would now use the weak
>> arch_scale_freq_power which calls default_scale_freq_power. Isn't it
>> enough ?
>
> ---
> Subject: sched, x86: Remove broken power estimation
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Wed Jun 13 15:24:45 CEST 2012
>
> The x86 sched power implementation has been broken forever and gets in
> the way of other stuff, remove it.
>
> For archaeological interest, fixing this code would require dealing with
> the cross-cpu calling of these functions and more importantly, we need
> to filter idle time out of the a/m-perf stuff because the ratio will go
> down to 0 when idle, giving a 0 capacity which is not what we'd want.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Link: http://lkml.kernel.org/n/tip-wjjwelpti8f8k7i1pdnzmdr8 at git.kernel.org
> ---
> ?arch/x86/kernel/cpu/Makefile | ? ?2 -
> ?arch/x86/kernel/cpu/sched.c ?| ? 55 -------------------------------------------
> ?2 files changed, 1 insertion(+), 56 deletions(-)
>
> --- a/arch/x86/kernel/cpu/Makefile
> +++ b/arch/x86/kernel/cpu/Makefile
> @@ -14,7 +14,7 @@ CFLAGS_common.o ? ? ? ? ? ? ? := $(nostackp)
>
> ?obj-y ? ? ? ? ? ? ? ? ?:= intel_cacheinfo.o scattered.o topology.o
> ?obj-y ? ? ? ? ? ? ? ? ?+= proc.o capflags.o powerflags.o common.o
> -obj-y ? ? ? ? ? ? ? ? ?+= vmware.o hypervisor.o sched.o mshyperv.o
> +obj-y ? ? ? ? ? ? ? ? ?+= vmware.o hypervisor.o mshyperv.o
> ?obj-y ? ? ? ? ? ? ? ? ?+= rdrand.o
> ?obj-y ? ? ? ? ? ? ? ? ?+= match.o
>
> --- a/arch/x86/kernel/cpu/sched.c
> +++ /dev/null
> @@ -1,55 +0,0 @@
> -#include <linux/sched.h>
> -#include <linux/math64.h>
> -#include <linux/percpu.h>
> -#include <linux/irqflags.h>
> -
> -#include <asm/cpufeature.h>
> -#include <asm/processor.h>
> -
> -#ifdef CONFIG_SMP
> -
> -static DEFINE_PER_CPU(struct aperfmperf, old_perf_sched);
> -
> -static unsigned long scale_aperfmperf(void)
> -{
> - ? ? ? struct aperfmperf val, *old = &__get_cpu_var(old_perf_sched);
> - ? ? ? unsigned long ratio, flags;
> -
> - ? ? ? local_irq_save(flags);
> - ? ? ? get_aperfmperf(&val);
> - ? ? ? local_irq_restore(flags);
> -
> - ? ? ? ratio = calc_aperfmperf_ratio(old, &val);
> - ? ? ? *old = val;
> -
> - ? ? ? return ratio;
> -}
> -
> -unsigned long arch_scale_freq_power(struct sched_domain *sd, int cpu)
> -{
> - ? ? ? /*
> - ? ? ? ?* do aperf/mperf on the cpu level because it includes things
> - ? ? ? ?* like turbo mode, which are relevant to full cores.
> - ? ? ? ?*/
> - ? ? ? if (boot_cpu_has(X86_FEATURE_APERFMPERF))
> - ? ? ? ? ? ? ? return scale_aperfmperf();
> -
> - ? ? ? /*
> - ? ? ? ?* maybe have something cpufreq here
> - ? ? ? ?*/
> -
> - ? ? ? return default_scale_freq_power(sd, cpu);
> -}
> -
> -unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
> -{
> - ? ? ? /*
> - ? ? ? ?* aperf/mperf already includes the smt gain
> - ? ? ? ?*/
> - ? ? ? if (boot_cpu_has(X86_FEATURE_APERFMPERF))
> - ? ? ? ? ? ? ? return SCHED_LOAD_SCALE;
> -
> - ? ? ? return default_scale_smt_power(sd, cpu);
> -}
> -
> -#endif
>

Sorry for the misses, I need to update my tags because this has been filtered.

      reply	other threads:[~2012-06-13 13:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-12 12:02 [RFC 0/4] ARM: topology: set the capacity of each cores for big.LITTLE Vincent Guittot
2012-06-12 12:02 ` [RFC 1/4] ARM: topology: Add arch_scale_freq_power function Vincent Guittot
2012-06-13  8:50   ` Jean Pihet
2012-06-13  9:22     ` Vincent Guittot
2012-06-13 12:52   ` Peter Zijlstra
2012-06-13 19:27     ` Andy Whitcroft
2012-06-13 19:30       ` Joe Perches
2012-06-13 21:51       ` Peter Zijlstra
2012-06-12 12:02 ` [RFC 2/4] ARM: topology: factorize the update of sibling masks Vincent Guittot
2012-06-13 12:54   ` Peter Zijlstra
2012-06-12 12:02 ` [RFC 3/4] ARM: topology: Update cpu_power according to DT information Vincent Guittot
2012-06-13  8:59   ` Jean Pihet
2012-06-13  9:44     ` Vincent Guittot
2012-06-13 12:44       ` Amit Kucheria
2012-06-13 12:47         ` Peter Zijlstra
2012-06-13 12:50           ` Jean Pihet
2012-06-13 13:29           ` Vincent Guittot
2012-06-13 13:32             ` Peter Zijlstra
2012-06-13 14:31               ` Vincent Guittot
2012-06-13 13:07   ` Peter Zijlstra
2012-06-13 14:54     ` Vincent Guittot
2012-06-13 16:06       ` Peter Zijlstra
2012-06-13 13:09   ` Peter Zijlstra
2012-06-13 14:42     ` Nicolas Pitre
2012-06-13 13:19   ` Peter Zijlstra
2012-06-12 12:02 ` [RFC 4/4] sched: cpu_power: enable ARCH_POWER Vincent Guittot
2012-06-13 12:50   ` Peter Zijlstra
2012-06-13 13:20     ` Vincent Guittot
2012-06-13 13:28       ` Peter Zijlstra
2012-06-13 13:50         ` Vincent Guittot [this message]

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=CAKfTPtAbmLy5hR-W7RMQpn1cf1jkirv0oNtS_h4dmPYx5gTm1w@mail.gmail.com \
    --to=vincent.guittot@linaro.org \
    --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).