On Wed, May 22, 2013 at 02:04:16PM +0530, Viresh Kumar wrote:
> So, this is the clean draft for the idea I had.. (Naming is poor for
> now):
>
> diff --git a/include/linux/timer.h b/include/linux/timer.h
> index 8c5a197..ad00ebe 100644
> --- a/include/linux/timer.h
> +++ b/include/linux/timer.h
>
On Thu, 2012-10-25 at 23:42 +0530, Preeti U Murthy wrote:
> > Do explain..
> >
> Let me see if I get what you are saying here right.You want to replace
> for example cfs_rq->load.weight with a saner metric because it does not
> consider the run time of the sched entities queued on it,merely their
OK, so I tried reading a few patches and I'm completely failing.. maybe
its late and my brain stopped working, but it simply doesn't make any
sense.
Most changelogs and comments aren't really helping either. At best they
mention what you're doing, not why and how. This means I get to
basically dup
On Tue, 2012-09-25 at 13:40 +0200, Peter Zijlstra wrote:
> On Tue, 2012-09-25 at 17:00 +0530, Viresh Kumar wrote:
> > But this is what the initial idea during LPC we had.
>
> Yeah.. that's true.
>
> > Any improvements here you can suggest?
>
> We could uhm..
On Tue, 2012-09-25 at 17:00 +0530, Viresh Kumar wrote:
> But this is what the initial idea during LPC we had.
Yeah.. that's true.
> Any improvements here you can suggest?
We could uhm... /me tries thinking ... reuse some of the NOHZ magic?
Would that be sufficient, not waking a NOHZ cpu, or do
On Tue, 2012-09-25 at 16:06 +0530, Viresh Kumar wrote:
> @@ -1066,8 +1076,9 @@ int queue_work(struct workqueue_struct *wq,
> struct work_struct *work)
> {
> int ret;
>
> - ret = queue_work_on(get_cpu(), wq, work);
> - put_cpu();
> + preempt_disable();
> + ret = qu
On Tue, 2012-09-25 at 16:06 +0530, Viresh Kumar wrote:
> +/* sched-domain levels */
> +#define SD_SIBLING 0x01/* Only for CONFIG_SCHED_SMT */
> +#define SD_MC 0x02/* Only for CONFIG_SCHED_MC */
> +#define SD_BOOK0x04/* Only for CONFIG
On Thu, 2012-09-13 at 11:17 +0200, Vincent Guittot wrote:
> On 10 July 2012 15:42, Peter Zijlstra wrote:
> > On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
> >>
> >> May be the last one which enable ARCH_POWER should also go into tip ?
> >>
> >
On Thu, 2012-09-13 at 10:45 +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-13 at 10:37 +0200, Vincent Guittot wrote:
> > > I think you need to present numbers showing benefit. Crawling all over
> > > a mostly idle (4096p?) box is decidedly bad thing to do.
>
> Yeah, b
On Thu, 2012-09-13 at 10:37 +0200, Vincent Guittot wrote:
> > I think you need to present numbers showing benefit. Crawling all over
> > a mostly idle (4096p?) box is decidedly bad thing to do.
Yeah, but we're already doing that anyway.. we know nohz idle balance
doesn't scale. Venki and Suresh
On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote:
> On tickless system, one CPU runs load balance for all idle CPUs.
> The cpu_load of this CPU is updated before starting the load balance
> of each other idle CPUs. We should instead update the cpu_load of the
> balance_cpu.
>
> Signed-off
On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote:
> On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote:
> > On tickless system, one CPU runs load balance for all idle CPUs.
> > The cpu_load of this CPU is updated before starting the load balance
> > of each other idle CPUs. We should
On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
>
> May be the last one which enable ARCH_POWER should also go into tip ?
>
OK, I can take it.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/li
parse_dt_topology
>
> Modification since v1:
> - Add and update explanation about the use of the table and the range of the
> value
> - Remove the use of NR_CPUS and use nr_cpu_ids instead
> - Remove broken power estimation of x86
>
> Peter Zijlstra (1):
> sched, x86: R
On Mon, 2012-07-09 at 16:25 +0530, Shilimkar, Santosh wrote:
> Having that support would greatly help for the SOC's which have not
> yet
> reached to stage where entire SOC is DT compliant and want to use
> big.LITTLE infrastructure.
Good incentive to get there though.. :-)
_
On Mon, 2012-07-02 at 14:11 +0200, Vincent Guittot wrote:
> max / (min + max) * 2^11 so the cpu_scale is smaller than 2^11 as min
> is never equal to 0
D'0h right.. I think I confused the middle thing with avg again.
___
linaro-dev mailing list
linar
On Wed, 2012-06-20 at 17:19 +0200, Vincent Guittot wrote:
> +#ifdef CONFIG_OF
> +struct cpu_efficiency {
> + const char *compatible;
> + unsigned long efficiency;
> +};
> +
> +/*
> + * Table of relative efficiency of each processors
> + * The efficiency value must fit in 20bit. The fina
On Wed, 2012-06-20 at 11:11 +0200, Vincent Guittot wrote:
> On 19 June 2012 11:01, Yong Zhang wrote:
> > On Tue, Jun 19, 2012 at 10:28:56AM +0200, Vincent Guittot wrote:
> >> Heteregeneous ARM platform uses arch_scale_freq_power function
> >> to reflect the relative capacity of each core
> >>
> >>
On Wed, 2012-06-13 at 20:27 +0100, Andy Whitcroft wrote:
> Actually if it was a new line, it would have been reported, at least in
> theory:
>
> # check for memory barriers without a comment.
> if ($line =~
>
> /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|
On Wed, 2012-06-13 at 16:54 +0200, Vincent Guittot wrote:
> On 13 June 2012 15:07, Peter Zijlstra wrote:
> > On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> >> +struct cpu_capacity cpu_capacity[NR_CPUS];
> >
> > I know ARM isn't likely to suffer fr
On Wed, 2012-06-13 at 15:29 +0200, Vincent Guittot wrote:
> In fact, there is 2 tracks, one for a power aware scheduler and one
> for setting the capacity of each core of a big.LITTLE system. This
> patch is for the latter and is not directly link to the power because
> the default/performance mode
x86: Remove broken power estimation
From: Peter Zijlstra
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
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> Use cpu compatibility field and clock-frequency field of DT to
> estimate the capacity of each core of the system
>
Can you provide a little description in the form of a code comment near
update_cpu_power() as to wtf all that does? This O
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> +#ifdef CONFIG_OF
That must really be the worst CONFIG_ name ever..
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> +struct cpu_capacity cpu_capacity[NR_CPUS];
I know ARM isn't likely to suffer from the 4k cpu issue, but is there a
reason to use a NR_CPUS array over a per-cpu variable?
___
linaro-dev mailing
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> + smp_wmb();
No cookies for Vince!
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> }
> smp_wmb();
> }
You know what.. we should make checkpatch report an error for memory
barriers that don't have a comment.
I know this isn't added by this patch, but every time I see something
like it I cry a little.
On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> Heteregeneous ARM platform uses arch_scale_freq_power function
> to reflect the relative capacity of each core
I think I've pointed out before that this breaks x86.. you need a patch
killing at that stuff before this.
> Signed-off-by: Vi
On Wed, 2012-06-13 at 18:14 +0530, Amit Kucheria wrote:
> Various discussions around power-aware scheduling have amplified the
> need for the scheduler to have some knowledge of DVFS. This would then
> require the scheduler to track 'cpu_power' ( = max power) and perhaps
> a new variable 'current_p
On Mon, 2012-02-20 at 10:04 +0400, Dmitry Antipov wrote:
> Generalize CONFIG_IRQ_TIME_ACCOUNTING between X86 and
> ARM, move "noirqtime=" option to common debugging code.
> For a bit of backward compatibility, X86-specific option
> "tsc=noirqtime" is preserved, but issues a warning.
>
> Suggested
On Wed, 2012-01-04 at 09:22 +0100, Vincent Guittot wrote:
> Does it sound good for you if I update the comment of this patch with
> the explanation of the previous mails or do you need more information
> ?
>
No, looks ok. Just got stuck in the mailbox + extra holidays delay.
Got it queued now, Th
On Mon, 2011-12-12 at 20:21 +0100, Vincent Guittot wrote:
> With a lot of small tasks, the softirq sched is nearly never called
> when no_hz is enable. In this case the load_balance is mainly called with
> the newly_idle mode which doesn't update the cpu_power.
> Add a next_update field which ensur
On Tue, 2011-10-11 at 18:03 +0200, Vincent Guittot wrote:
> > How do you know the task is 'small' ?
> >
>
> I want to use cpufreq to be notified that we have a large/small cpu
> load. If we have several tasks but the cpu uses the lowest frequency,
> it "should" mean that we have small tasks that a
On Tue, 2011-10-11 at 11:40 +0200, Vincent Guittot wrote:
> On 11 October 2011 11:13, Peter Zijlstra wrote:
> > On Tue, 2011-10-11 at 10:51 +0200, Vincent Guittot wrote:
> >> I have several goals. The 1st one is that I need to put more load on
> >> some cpus when I h
On Tue, 2011-10-11 at 10:51 +0200, Vincent Guittot wrote:
> I have several goals. The 1st one is that I need to put more load on
> some cpus when I have packages with different cpu frequency.
That should be rather easy.
> I also study if I can follow the real cpu frequency but it seems to be
> no
On Tue, 2011-10-11 at 12:46 +0530, Amit Kucheria wrote:
> Adding Peter to the discussion..
Right, CCing the folks who actually wrote the code you're asking
questions about always helps ;-)
> On Thu, Oct 6, 2011 at 5:06 PM, Vincent Guittot
> wrote:
> > I work to link the cpu_power of ARM cores to
On Tue, 2011-10-11 at 15:08 +0530, Amit Kucheria wrote:
> > That shouldn't be done using cpu_power, we have sched_smt_power_savings
> > and sched_mc_power_savings for stuff like that.
>
> AFAICT, sched_mc assume all cores to have the same capacity - which is
> certainly true of the x86 architectu
CPU.
>
> The purpose of this new cpumask is to aid kernel code which uses CPU to
> take CPUs online and offline. Possible uses are as a thermal event
> mitigation technique or as a power capping mechanism.
Nacked-by: Peter Zijlstra
the kernel really shouldn't be using hotpl
On Thu, 2011-08-11 at 12:25 -0700, Turquette, Mike wrote:
> On Thu, Aug 11, 2011 at 11:30 AM, Peter Zijlstra wrote:
> > On Wed, 2011-08-10 at 13:03 -0700, Mike Turquette wrote:
> >> This patch series introduces a new cpumask which tracks CPUs that
> >> support hotplu
e entire dance of hotplug just to idle a
cpu? Hotplug not only idles the cpu but tears down (and rebuilds) an
insane amount of resources associated with the cpu.
Nacked-by: Peter Zijlstra
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://
40 matches
Mail list logo
