[lkml]   [2015]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/1] suspend: delete sys_sync()
On Fri, 8 May 2015, Len Brown wrote:

> From: Len Brown <>
> 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

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

Alan Stern

 \ /
  Last update: 2015-05-08 16:41    [W:0.165 / U:28.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site