Morten Rasmussen | 7 Jul 20:23 2015

[RFCv5 PATCH 00/46] sched: Energy cost model for energy-aware scheduling

Several techniques for saving energy through various scheduler
modifications have been proposed in the past, however most of the
techniques have not been universally beneficial for all use-cases and
platforms. For example, consolidating tasks on fewer cpus is an
effective way to save energy on some platforms, while it might make
things worse on others. At the same time there has been a demand for
scheduler driven power management given the scheduler's position to
judge performance requirements for the near future [1].

This proposal, which is inspired by [1] and the Ksummit workshop
discussions in 2013 [2], takes a different approach by using a
(relatively) simple platform energy cost model to guide scheduling
decisions. By providing the model with platform specific costing data
the model can provide an estimate of the energy implications of
scheduling decisions. So instead of blindly applying scheduling
techniques that may or may not work for the current use-case, the
scheduler can make informed energy-aware decisions. We believe this
approach provides a methodology that can be adapted to any platform,
including heterogeneous systems such as ARM big.LITTLE. The model
considers cpus only, i.e. no peripherals, GPU or memory. Model data
includes power consumption at each P-state and C-state. Furthermore a
natural extension of this proposal is to drive P-state selection from
the scheduler given its awareness of changes in cpu utilization.

This is an RFC but contains most of the essential features. The model
and its infrastructure is in place in the scheduler and it is being used
for load-balancing decisions. The energy model data is hardcoded and
there are some limitations still to be addressed. However, the main
ideas are presented here, which is the use of an energy model for
scheduling decisions and scheduler-driven DVFS.
(Continue reading)

Pan Xinhui | 7 Jul 14:43 2015
Picon

[PATCH V2] acpi-cpufreq: replace per_cpu with driver_data of policy


Drivers can store their internal per-policy information in
policy->driver_data, lets use it.

we have benefits after this replacing.
1) memory saving.
2) policy is shared by several cpus, per_cpu seems not correct. using
*driver_data* is more reasonable.
3) fix a memory leak in acpi_cpufreq_cpu_exit. as policy->cpu might
change during cpu hotplug. So sometimes we cant't free *data*, use
*driver_data* to fix it.
4) fix a zero return value of get_cur_freq_on_cpu. Only per_cpu of
policy->cpu is set to *data*, if we try to get cpufreq on other cpus, we
get zero instead of correct values. Use *driver_data* to fix it.

Signed-off-by: Pan Xinhui <xinhuix.pan <at> intel.com>
---
Changes from V1:
	codes style fix, comments update
	move cpufreq_cpu_put(policy) after we get *driver_data*
---
 drivers/cpufreq/acpi-cpufreq.c | 40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 0136dfc..e7fcaa6 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
 <at>  <at>  -72,8 +72,6  <at>  <at>  struct acpi_cpufreq_data {
 	cpumask_var_t freqdomain_cpus;
(Continue reading)

Pan Xinhui | 7 Jul 12:29 2015
Picon

[PATCH] acpi-cpufreq: replace per_cpu with driver_data of policy


Now policy has field of driver_data, we can use it to get rid of per_cpu
acpi_cpufreq_data.

we have benefits after this replacing.  1) memory saving.  2) policy is
shared by several cpus, per_cpu seems not correct.  useing *driver_data*
is more reasonable.  3) fix a memory leak in acpi_cpufreq_cpu_exit.  as
policy->cpu might change after cpu hotplug. So sometimes we cant't free
*data*, use *driver_data* to fix it.  4) fix a zero return value of
get_cur_freq_on_cpu.  Only per_cpu(policy->cpu) is set to *data*, if we
try to get cpufreq on other cpus, we get zero instead of correct values.
Use *driver_data* to fix it.

Signed-off-by: Pan Xinhui <xinhuix.pan <at> intel.com>
---
 drivers/cpufreq/acpi-cpufreq.c | 38 +++++++++++++++++++++++---------------
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 0136dfc..7f662dd 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
 <at>  <at>  -72,8 +72,6  <at>  <at>  struct acpi_cpufreq_data {
 	cpumask_var_t freqdomain_cpus;
 };

-static DEFINE_PER_CPU(struct acpi_cpufreq_data *, acfreq_data);
-
 /* acpi_perf_data is a pointer to percpu data. */
 static struct acpi_processor_performance __percpu *acpi_perf_data;
(Continue reading)

kbuild test robot | 7 Jul 01:47 2015
Picon

[pm:bleeding-edge 2/10] drivers/acpi/scan.c:2131:25: error: 'struct acpi_device_info' has no member named 'cls'

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
head:   e3b3968310369aadfa5c1f7baca68ef37bfd1d38
commit: 1f9cda6095d7073ae96c27b1dbfd8d3fa71a85d3 [2/10] ACPI / scan: Add support for ACPI _CLS device matching
config: x86_64-lkp (attached as .config)
reproduce:
  git checkout 1f9cda6095d7073ae96c27b1dbfd8d3fa71a85d3
  # save the attached .config to linux build tree
  make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/acpi/scan.c: In function 'acpi_set_pnp_ids':
>> drivers/acpi/scan.c:2131:25: error: 'struct acpi_device_info' has no member named 'cls'
       acpi_add_id(pnp, info->cls.string);
                            ^

vim +2131 drivers/acpi/scan.c

  2125				pnp->type.bus_address = 1;
  2126			}
  2127			if (info->valid & ACPI_VALID_UID)
  2128				pnp->unique_id = kstrdup(info->unique_id.string,
  2129								GFP_KERNEL);
  2130			if (info->valid & ACPI_VALID_CLS)
> 2131				acpi_add_id(pnp, info->cls.string);
  2132	
  2133			kfree(info);
  2134	

---
(Continue reading)

Felipe Balbi | 6 Jul 20:09 2015
Picon

Re: [PATCH] base: power: wakeirq: don't leak dev->power.wakeirq

On Mon, Jul 06, 2015 at 08:06:17PM +0200, Michael Trimarchi wrote:
> Hi
> 
> On Jul 6, 2015 8:01 PM, "Felipe Balbi" <balbi <at> ti.com> wrote:
> >
> > on a first call to dev_pm_attach_wake_irq(), if it
> > fails, it will leave dev->power.wakeirq set to a
> > dangling pointer. Instead, let's clear it to make
> > sure a subsequent call to dev_pm_attach_wake_irq()
> > has chance to succeed.
> >
> > Cc: Tony Lindgren <tmlind <at> atomide.com>
> > Signed-off-by: Felipe Balbi <balbi <at> ti.com>
> > ---
> >  drivers/base/power/wakeirq.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c
> > index 7470004ca810..394d250a1ad8 100644
> > --- a/drivers/base/power/wakeirq.c
> > +++ b/drivers/base/power/wakeirq.c
> >  <at>  <at>  -50,9 +50,16  <at>  <at>  static int dev_pm_attach_wake_irq(struct device *dev,
> int irq,
> >
> >         err = device_wakeup_attach_irq(dev, wirq);
> >         if (err)
> > -               return err;
> > +               goto err_cleanup;
> >
> >         return 0;
(Continue reading)

Lukasz Majewski | 6 Jul 17:26 2015

[GIT PULL] Samsung Thermal FIXES for v4.2-rc1

Dear Eduardo,

Please find my pull request for Samsung Thermal fixes (v4.2-rc1):

The following changes since commit
efa86858e1d8970411a140fa1e0c4dd18a8f2a89:

  thermal: armada: Update Armada 380 thermal sensor coefficients
  (2015-05-09 01:00:31 -0700)

are available in the git repository at:

  git <at> github.com:lmajewski/linux-samsung-thermal.git fixes

for you to fetch changes up to e4dc28277205cfb02f8dd96fe694a1bcc2dc41b1:

  thermal: exynos: Remove unused code related to platform_data on
  probe() (2015-07-06 17:09:15 +0200)

----------------------------------------------------------------
Chanwoo Choi (2):
      thermal: exynos: Add the dependency of CONFIG_THERMAL_OF instead
of CONFIG_OF thermal: exynos: Remove unused code related to
platform_data on probe()

Krzysztof Kozlowski (1):
      thermal: exynos: Disable the regulator on probe failure

 drivers/thermal/samsung/Kconfig      | 2 +-
 drivers/thermal/samsung/exynos_tmu.c | 5 ++---
(Continue reading)

Jun Nie | 6 Jul 10:35 2015

[PATCH v2] power/reset: zx: Register restart handler

Register with kernel restart handler instead of setting arm_pm_restart
directly.

Signed-off-by: Jun Nie <jun.nie <at> linaro.org>
---
 drivers/power/reset/Kconfig     |  7 ++++
 drivers/power/reset/Makefile    |  1 +
 drivers/power/reset/zx-reboot.c | 82 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 90 insertions(+)
 create mode 100644 drivers/power/reset/zx-reboot.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index aad9c33..4ed90f3 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
 <at>  <at>  -165,5 +165,12  <at>  <at>  config POWER_RESET_RMOBILE
 	help
 	  Reboot support for Renesas R-Mobile and SH-Mobile SoCs.

+config POWER_RESET_ZX
+	tristate "ZTE SoCs reset driver"
+	depends on ARCH_ZX || COMPILE_TEST
+	depends on HAS_IOMEM
+	help
+	  Reboot support for ZTE SoCs.
+
 endif

diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index dbe06c3..096fa67 100644
(Continue reading)

Sascha Hauer | 6 Jul 09:19 2015
Picon

[PATCH] thermal: consistently use int for temperatures

The thermal code uses int, long and unsigned long for temperatures
in different places.

Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.

'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.

Consistently use a plain 'int' for temperatures throughout the thermal code and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.

Signed-off-by: Sascha Hauer <s.hauer <at> pengutronix.de>
Cc: Zhang Rui <rui.zhang <at> intel.com>
Cc: Eduardo Valentin <edubezval <at> gmail.com>
Cc: linux-pm <at> vger.kernel.org
Cc: linux-kernel <at> vger.kernel.org
Cc: Jean Delvare <jdelvare <at> suse.de>
Cc: Peter Feuerer <peter <at> piie.net>
Cc: Heiko Stuebner <heiko <at> sntech.de>
Cc: Lukasz Majewski <l.majewski <at> samsung.com>
Cc: Stephen Warren <swarren <at> wwwdotorg.org>
Cc: Thierry Reding <thierry.reding <at> gmail.com>
Cc: linux-acpi <at> vger.kernel.org
Cc: platform-driver-x86 <at> vger.kernel.org
(Continue reading)

Pan Xinhui | 6 Jul 08:30 2015
Picon

[PATCH] acpi-cpufreq.c: fix a memory leak in acpi_cpufreq_cpu_exit


policy->cpu in acpi_cpufreq_cpu_init/exit is the same cpu in most cases.
However during cpu hotplug,
cpufreq core might nominate a new cpu for policy->cpu.

Thar will cause a memory leak in acpi_cpufreq_cpu_exit.
To avoid this issue, use field *driver_data* to keep the the pointer
of acpi_cpufreq_data.

Add field *cpu* in acpi_cpufreq_data to do some proper cleanup work.

Signed-off-by: Pan Xinhui <xinhuix.pan <at> intel.com>
---
 drivers/cpufreq/acpi-cpufreq.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 0136dfc..1f3372a 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
 <at>  <at>  -70,6 +70,7  <at>  <at>  struct acpi_cpufreq_data {
 	unsigned int resume;
 	unsigned int cpu_feature;
 	cpumask_var_t freqdomain_cpus;
+	unsigned int cpu;
 };

 static DEFINE_PER_CPU(struct acpi_cpufreq_data *, acfreq_data);
 <at>  <at>  -833,6 +834,9  <at>  <at>  static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	 */
(Continue reading)

Lucas Stach | 3 Jul 16:19 2015
Picon

[PATCH] idle: move latency tracing stop/start calls deeper inside the idle loop

Make sure to stop tracing only once we are past a point where all
latency tracing events have been processed (irqs are not enabled
again). This has the slight advantage of capturing more latency
related events in the idle path, but most importantly it makes sure
that latency tracing doesn't get re-enabled inadvertently when
new events are coming in.

This makes the irqsoff latency tracer useful again, as we stop
capturing CPU sleep time as IRQ latency.

Signed-off-by: Lucas Stach <l.stach <at> pengutronix.de>
---
 drivers/cpuidle/cpuidle.c |  2 ++
 kernel/sched/idle.c       | 14 +++++---------
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 61c417b9e53f..d78514ac3f5d 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
 <at>  <at>  -173,7 +173,9  <at>  <at>  int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
 	trace_cpu_idle_rcuidle(index, dev->cpu);
 	time_start = ktime_get();

+	stop_critical_timings();
 	entered_state = target_state->enter(dev, drv, index);
+	start_critical_timings();

 	time_end = ktime_get();
 	trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
(Continue reading)

Javi Merino | 3 Jul 14:58 2015

[PATCH 0/4] Devfreq cooling device

This series introduces a devfreq cooling device in the thermal
framework.  Devfreq is used for DVFS for devices other than the CPUs.
With a devfreq cooling device, the thermal framework can throttle them
to control temperature.  The cooling device has the power extensions,
so it can be used by all governors in the thermal framework, including
the power allocator governor.

Javi Merino (2):
  devfreq: cache the last call to get_dev_status()
  devfreq_cooling: add trace information

Ørjan Eide (2):
  PM / devfreq: Add function to set max/min frequency
  thermal: Add devfreq cooling

 drivers/devfreq/devfreq.c                 |  77 ++++--
 drivers/devfreq/governor_simpleondemand.c |  33 +--
 drivers/thermal/Kconfig                   |  10 +
 drivers/thermal/Makefile                  |   3 +
 drivers/thermal/devfreq_cooling.c         | 395 ++++++++++++++++++++++++++++++
 include/linux/devfreq.h                   |  20 ++
 include/linux/devfreq_cooling.h           |  90 +++++++
 include/trace/events/thermal.h            |  51 ++++
 8 files changed, 640 insertions(+), 39 deletions(-)
 create mode 100644 drivers/thermal/devfreq_cooling.c
 create mode 100644 include/linux/devfreq_cooling.h

--

-- 
1.9.1

(Continue reading)


Gmane