lkml.org 
[lkml]   [2015]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 1/1] suspend: delete sys_sync()
    From
    >> The _vast_ majority of systems using Linux suspend today are under
    >> an Android user-space. Android has no assumption that that suspend to
    >> mem will necessarily stay suspended for a long time.
    >
    > Indeed, however your change was not android-specific, and it is not
    > "comfortable" on x86-style hardware and usage patterns.

    "comfortable on x86-style and usage patterns"?
    If you mean "traditional" instead of "comfortable",
    where "tradition" is based on 10-year old systems, then sure.

    But today, my x86 Android tablet is quite "comfortable"
    without a sys_sync() in the kernel suspend path.

    No, this isn't Android specific, Android is just the highest-volume demand,
    making it an obvious example.

    Chrome is the #1 selling "x86-style" clamshell laptop.
    Chrome is not only "comfortable" with fast suspend/resume,
    the Chrome developers demand it.

    > That said, as long as x86 will still try to safeguard my data during mem
    > sleep/resume as it does today, I have no strong feelings about
    > light/heavy-weight "mem" sleep being strictly a compile-time selectable
    > thing, or a more flexible runtime-selectable behavior.

    The observation here is that the kernel should not force every system
    to sys_sync() on every suspend. The only question is how to best
    implement that. The obvious solution was to delete this forced policy
    from the kernel, and let user-space handle it.
    Rafael has not agreed to push that obvious, though less-than-gentle
    solution upstream, and so I'll re-send the historic patch
    that allows distros to still sync like it is 1999, if they want to:-)

    thanks,
    Len Brown, Intel Open Source Technology Center


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