Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751916AbbEIT7u (ORCPT ); Sat, 9 May 2015 15:59:50 -0400 Received: from netrider.rowland.org ([192.131.102.5]:52698 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751554AbbEIT7h (ORCPT ); Sat, 9 May 2015 15:59:37 -0400 Date: Sat, 9 May 2015 15:59:36 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: "Rafael J. Wysocki" cc: Len Brown , One Thousand Gnomes , Linux PM list , "linux-kernel@vger.kernel.org" , Len Brown Subject: Re: [PATCH 1/1] suspend: delete sys_sync() In-Reply-To: <4290667.ZqInAykFGS@vostro.rjw.lan> 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: 1212 Lines: 27 On Fri, 8 May 2015, Rafael J. Wysocki wrote: > My current view on that is that whether or not to do a sync() before suspending > ultimately is a policy decision and should belong to user space as such (modulo > the autosleep situation when user space may not know when the suspend is going > to happen). > > Moreover, user space is free to do as many sync()s before suspending as it > wants to and the question here is whether or not the *kernel* should sync() > in the suspend code path. > > Since we pretty much can demonstrate that having just one sync() in there is > not sufficient in general, should we put two of them in there? Or just > remove the existing one and leave it to user space entirely? I don't know about the advantages of one sync over two. But how about adding a "syncs_before_suspend" (or just "syncs") sysfs attribute that takes a small numeric value? The default can be 0, and the user could set it to 1 or 2 (or higher). 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/