[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1505081026250.1219-100000@iolanthe.rowland.org>
Date: Fri, 8 May 2015 10:34:13 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Len Brown <lenb@...nel.org>
cc: rjw@...ysocki.net, <linux-pm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, Len Brown <len.brown@...el.com>
Subject: Re: [PATCH 1/1] suspend: delete sys_sync()
On Fri, 8 May 2015, Len Brown wrote:
> From: Len Brown <len.brown@...el.com>
>
> Remove sys_sync() from the kernel's suspend flow.
>
> sys_sync() is extremely expensive in some configurations,
> and so the kernel should not force users to pay this cost
> on every suspend.
>
> The user-space utilities s2ram and s2disk choose to invoke sync() today.
> A user can invoke suspend directly via /sys/power/state to skip that cost.
I can understand the motivation for this, but is it aimed in the right
direction?
Consider a system where sys_sync() is very expensive. Should such a
system be using system suspend in the first place? If there is a valid
use case, why does the extra overhead of sys_sync() matter?
To put it another way, if the system wants to go into a low-latency
suspend state, why doesn't it use an extreme version of runtime suspend
rather than system suspend?
This reminds me of the discussions we had with the Android developers
when they proposed adding wakelocks to the kernel -- they needed them
so that they could support system suspend when what they really wanted
to do was an extreme version of runtime suspend. But generally
speaking, sys_sync() is not tremendously expensive on devices running
Android.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists