devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linaro-dev@lists.linaro.org,
	devicetree-discuss@lists.ozlabs.org, linux@arm.linux.org.uk,
	grant.likely@secretlab.ca, rob.herring@calxeda.com
Subject: Re: [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@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
     [not found] ` <1339502524-10265-1-git-send-email-vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
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
     [not found]     ` <1339502524-10265-4-git-send-email-vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
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=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linaro-dev@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=peterz@infradead.org \
    --cc=rob.herring@calxeda.com \
    /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).