diff mbox

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

Message ID 1452619040-27137-2-git-send-email-l.stach@pengutronix.de (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Lucas Stach Jan. 12, 2016, 5:17 p.m. UTC
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(-)

Comments

Pavel Machek Jan. 13, 2016, 7:02 p.m. UTC | #1
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>
Rafael J. Wysocki Jan. 19, 2016, 12:28 a.m. UTC | #2
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

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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);