Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753013AbbEHOeR (ORCPT ); Fri, 8 May 2015 10:34:17 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:59508 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751353AbbEHOeO (ORCPT ); Fri, 8 May 2015 10:34:14 -0400 Date: Fri, 8 May 2015 10:34:13 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Len Brown cc: rjw@rjwysocki.net, , , Len Brown Subject: Re: [PATCH 1/1] suspend: delete sys_sync() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1499 Lines: 38 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/