On Fri, May 8, 2015 at 3:13 PM, One Thousand Gnomes <gno...@lxorguk.ukuu.org.uk> wrote: >> 2. worst case latency is obscene, there are examples of some >> syncs which take over 3,000 ms to complete. > > ATA is pretty open ended on this. I believe the vendors use 7 seconds > just for the cache flush as their limit because after 7 seconds some non > Linux OS's blow up. However if my suspend/resume crashes (as still I'm > sorry to say happens far too often) I don't want my last ten minutes of > work trashed. > >> Unfortunately, sys_sync() can be a significant pain point, >> even for systems that run Android. > > Android devices often have slow I/O devices coupled with a lot of memory > so yes that is true. > > There are however some very important reasons for using sync() in a > suspend > > - I can read data off the suspended machines disk volumes even though I > can't write to them. People do this. > > - Suspend requires the firmware, drivers and kernel all get it exactly > right. On a lot of machines therefore suspend is still a buggy pile of > crap. Sync is extremely valuable given that you can't be entirely > sure your system will resume. > > - Users habitually do stupid things like removing USB dongles from > suspended boxes and thinking afterwards. Perception is that the device > is off therefore you can unplug it. > > So I think its inappropriate to change the default. Allow users to turn > it off by all means, and I imagine many phones would use that.
FWIW, 18-months ago, I proposed a patch to make the sys_sync() optional "[PATCH 1/1] suspend: make sync() on suspend-to-RAM optional" and feedback was that fewer choices would be better. Note that user-space has full license both before and after this patch to sync(). Indeed, the s2disk and s2ram utilities do exactly that. > Some of this however is crappy suspend/resume handling. If the suspend > subsystem was doing its job then for the cases of timeout triggered > suspend it would have triggered most of the disk writes ten seconds > before it tried to suspend properly ;-) No problem, continue to use s2ram on your system -- and to the extent that sync works, your data will be on disk. (sync reliability is a different topic...) Understand, however, there are systems which suspend/resume reliably many times per second, making policy choice of having the kernel hard-code a sys_sync() into the suspend path a bad idea. thanks, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
