On Fri, 8 May 2015, Len Brown wrote: > From: Len Brown <len.br...@intel.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
