Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932184AbbEHQgI (ORCPT ); Fri, 8 May 2015 12:36:08 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:35449 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753168AbbEHQgE (ORCPT ); Fri, 8 May 2015 12:36:04 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 8 May 2015 12:36:02 -0400 X-Google-Sender-Auth: tLstJXF6Te5Ku1PIzmtnOz4hvy0 Message-ID: Subject: Re: [PATCH 1/1] suspend: delete sys_sync() From: Len Brown To: Alan Stern Cc: "Rafael J. Wysocki" , Linux PM list , "linux-kernel@vger.kernel.org" , Len Brown Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2703 Lines: 64 On Fri, May 8, 2015 at 10:34 AM, Alan Stern wrote: > 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? There are four significant issues with sys_sync() here: 1. It is not determinitic Some devices (and their caches) are quick on the 1st sync, and then slow on the 2nd sync etc. 2. worst case latency is obscene, there are examples of some syncs which take over 3,000 ms to complete. 3. It doesn't necessarily deliver on the assumed benefits. Rafael tells me that it depends on the file system exactly what sync does. Look no further than the fact that for two sync's in a row, the 2nd one may be slower. 4. Whether to sync or not is a policy choice, and that choice should be made by the user, not the kernel. Many systems today want to wake for a packet, process that packet, and get back to sleep as fast as possible. Jamming a sys_sync() in their wake doesn't make sense. > 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? There are systems where systems suspend is FAST, except for the sync. I can e-mail you the analyze_suspend output for such a system. > 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. Unfortunately, sys_sync() can be a significant pain point, even for systems that run Android. Len Brown, Intel Open Source Technology Center -- 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/