lkml.org 
[lkml]   [2015]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] suspend: delete sys_sync()
On Sat, 09 May 2015, Alan Stern wrote:
> 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).

IMO it would be much safer to both have that knob, and to set it to keep the
current behavior as the default. Userspace will adapt and change that knob
to whatever is sufficient based on what it does before signaling the kernel
to suspend.

A regression in sync-before-suspend is sure to cause data loss episodes,
after all. And, as far as bikeshedding goes, IMHO syncs_before_suspend is
self-explanatory, which would be a very good reason to use it instead of the
shorter requires-you-to-know-what-it-is-about "syncs".

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


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