Messages in this thread | | | Date | Thu, 8 Oct 2015 17:50:06 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional |
| |
On Sat 2015-08-01 01:56:19, Rafael J. Wysocki wrote: > On Friday, July 31, 2015 12:02:36 PM Len Brown wrote: > > On Wed, Jul 22, 2015 at 4:55 AM, Oliver Neukum <oneukum@suse.com> wrote: > > > On Wed, 2015-07-22 at 03:25 +0200, Rafael J. Wysocki wrote: > > >> And it is more pain for me to change the user space on each of them to > > >> write to the new sysfs file on every boot than to set a kernel Kconfig > > >> option once. > > > > > > So why at all? If you really need this in sysfs, why not write > > > something like "memfast" into /sys/power/state ? > > > > We fought this battle, and lost. > > > > When we came out with "freeze", which is faster than "mem", > > no user-space changed to take advantage of it. > > I do think that Chrome is going to use "freeze", so maybe it's not a lost > battle after all? > > The problem with "memfast" and similar things is we'd also need "freezefast" > and "standbyfast" then, for consistency if nothing else, which makes a little > sense to me. > > BTW, it should be noted that the whole "sync in the kernel is better, because > it doesn't race with user space writing to disks" argument was completely > bogus and useless, because in fact the sync in the kernel is done before > freezing user space and which means that it is susceptible to the very same > race condition as the sync from user space.
That seems like a bug to me... when did that start happening? I'm pretty sure it was originally done after freeze...
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |