Re: [RFC PATCH 02/16] sched: Introduce CONFIG_SCHED_ENERGY

[Morten Rasmussen]

On Sun, Jun 08, 2014 at 07:03:16AM +0100, Henrik Austad wrote:
> On Fri, May 23, 2014 at 07:16:29PM +0100, Morten Rasmussen wrote:
> > The Energy-aware scheduler implementation is guarded by
> > CONFIG_SCHED_ENERGY.
> > 
> > Signed-off-by: Dietmar Eggemann <dietmar.eggemann@xxxxxxx>
> > Signed-off-by: Morten Rasmussen <morten.rasmussen@xxxxxxx>
> > ---
> >  arch/arm/Kconfig |    5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index ab438cb..bfc3a85 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> 
> Is this going to be duplicate for each architecture enabling this? Why
> not make a kernel/Kconfig.energy and link to that from those
> architectures using it?

kernel/Kconfig.energy is better I think.

> 
> > @@ -1926,6 +1926,11 @@ config XEN
> >  	help
> >  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> >  
> > +config SCHED_ENERGY
> > +	bool "Energy-aware scheduling (EXPERIMENTAL)"
> > +	help
> > +	  Highly experimental energy aware task scheduling.
> > +
> 
> how about adding *slightly* more info here? :) (yes, yes, I know it's an RFC)

Fair point.

> 
> """
> Highly experimental energy aware task scheduling.
> 
> This will allow the kernel to keep track of energy required for
> different capacity levels for a given CPU. That way, the scheduler can
> make more informed decisions as to where a newly woken task should be
> placed. Heterogenous platform will benefit the most from this option.

Platforms with hierarchical power domains (for example, having ability
to power off groups of cpus and their caches) should see some benefit as
well.

> Enabling this will add a significant overhead for a task-switch.

The overhead is at task wakeup, task switch (as in task preemption)
should not be affected.

Thanks for the text. I will roll into v2.

Morten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/