lkml.org 
[lkml]   [2015]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 1/1] suspend: delete sys_sync()
    From
    On Fri, May 8, 2015 at 3:13 PM, One Thousand Gnomes
    <gnomes@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


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