| Message ID | 1452619040-27137-2-git-send-email-l.stach@pengutronix.de (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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>
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 --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);
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(-)