[PATCH 1/2] timer: add setup_deferrable_timer macro

[PATCH 1/2] timer: add setup_deferrable_timer macro

[Lucas Stach]

Add the trivial missing macro to setup a deferrable timer.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 include/linux/timer.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/timer.h b/include/linux/timer.h
index 61aa61dc410c..20ac746f3eb3 100644
--- a/include/linux/timer.h
+++ b/include/linux/timer.h
@@ -145,6 +145,8 @@ static inline void init_timer_on_stack_key(struct timer_list *timer,
 
 #define setup_timer(timer, fn, data)					\
 	__setup_timer((timer), (fn), (data), 0)
+#define setup_deferrable_timer(timer, fn, data)				\
+	__setup_timer((timer), (fn), (data), TIMER_DEFERRABLE)
 #define setup_timer_on_stack(timer, fn, data)				\
 	__setup_timer_on_stack((timer), (fn), (data), 0)
 #define setup_deferrable_timer_on_stack(timer, fn, data)		\
-- 
2.6.4

[PATCH 2/2] PM / Runtime: use deferrable timer for autosuspend

[Lucas Stach]

The timeouts used in PM autosuspend are relatively coarse (the shortest
I could find in a quick search through the kernel is 50ms). As they are
already handled relaxed by saving the overhead of always rearming the
timer by opportunistically suspending a device a bit early, it should
not matter if the the timeout is missed slightly.

By using a deferrable timer the CPU will not be woken just to handle
the autosuspend timeout, but handling will be batched with other
wakeups in the system.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 drivers/base/power/runtime.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index e1a10a03df8e..975a282600ff 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1383,7 +1383,7 @@ void pm_runtime_init(struct device *dev)
 	INIT_WORK(&dev->power.work, pm_runtime_work);
 
 	dev->power.timer_expires = 0;
-	setup_timer(&dev->power.suspend_timer, pm_suspend_timer_fn,
+	setup_deferrable_timer(&dev->power.suspend_timer, pm_suspend_timer_fn,
 			(unsigned long)dev);
 
 	init_waitqueue_head(&dev->power.wait_queue);
-- 
2.6.4

Re: [PATCH 2/2] PM / Runtime: use deferrable timer for autosuspend

[Pavel Machek]

On Tue 2016-01-12 18:17:20, Lucas Stach wrote:
> The timeouts used in PM autosuspend are relatively coarse (the shortest
> I could find in a quick search through the kernel is 50ms). As they are
> already handled relaxed by saving the overhead of always rearming the
> timer by opportunistically suspending a device a bit early, it should
> not matter if the the timeout is missed slightly.
> 
> By using a deferrable timer the CPU will not be woken just to handle
> the autosuspend timeout, but handling will be batched with other
> wakeups in the system.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

Acked-by: Pavel Machek <pavel@ucw.cz>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 2/2] PM / Runtime: use deferrable timer for autosuspend

[Rafael J. Wysocki]

On Tuesday, January 12, 2016 06:17:20 PM Lucas Stach wrote:
> The timeouts used in PM autosuspend are relatively coarse (the shortest
> I could find in a quick search through the kernel is 50ms). As they are
> already handled relaxed by saving the overhead of always rearming the
> timer by opportunistically suspending a device a bit early, it should
> not matter if the the timeout is missed slightly.
> 
> By using a deferrable timer the CPU will not be woken just to handle
> the autosuspend timeout, but handling will be batched with other
> wakeups in the system.

On some platforms this may increase energy consumption.

Say you have a deep platform-wide idle state (say it is called "C10").
Say this state can only be entered by the platform if device X has
been suspended.  The driver for X has an autosuspend delay of 50 ms,
but the platform can stay up to 0.5s in idle on the average.

Say the last CPU core goes idle and asks for "C10", but X hasn't been
suspended yet, so the platform enters a shallower idle state and
with this change applied it stays in that state for up to 0.5s, but
otherwise it would have been woken up by the X driver's autosuspend
timer and might be able to enter "C10" earlier.

So, I'm not really liking this change that much.

Thanks,
Rafael

Re: [PATCH 1/2] timer: add setup_deferrable_timer macro

[Thomas Gleixner]

On Tue, 12 Jan 2016, Lucas Stach wrote:

> Add the trivial missing macro to setup a deferrable timer.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

Acked-by: Thomas Gleixner <tglx@linutronix.de>

@Rafael: Feel free to pick that up along with the other one.