Hi,
it depends on how you look at it. You are looking at it from the point
of having the largest fail safety, then yes. However, as I see this, it
is mostly about preventing battery drain. i.e. enable users to suspend
their machines for a day or two and continue working on battery
afterwards.
With this criteria, you get:
1. simple 'suspend':
- High battery drain
- Fails on power loss
+ Fast suspend
+ Fast resume
2. suspend-then-hibernate:
+ Low battery drain
+ No failure on power loss
+ Fast suspend
+ Fast resume
3. hybrid-suspend:
- High battery drain
+ No failure on power loss
- Slow suspend
+ Fast resume
And with this criteria suspend-then-hibernate clearly wins.
You potentially get some more complications with s2i (suspend to idle)
in the future. One could for example leave the WiFi and TCP/IP
connections established for a period of time during suspend (but still
freeze userspace otherwise).
Benjamin
On Thu, 2018-09-13 at 17:03 -0700, Adam Williamson wrote:
> On Thu, 2018-09-13 at 16:55 -0700, Adam Williamson wrote:
> > On Thu, 2018-09-13 at 16:16 +0200, Benjamin Berg wrote:
> > > Hi,
> > >
> > > On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
> > > > This needs to be disabled in systemd, as I mentioned in the previous
> > > > thread.
> > > > This means it would still work in GNOME if somebody enables the feature
> > > > in systemd, as would be expected.
> > >
> > > Yeah, I agree that disabling it in systemd by default is likely the
> > > best way forward for F29. If we can get enough testing, then it may be
> > > possible to enable hibernation again for F30.
> > >
> > > gsd-power has no configuration option to change the behaviour. It will
> > > simply use SuspendThenHibernate rather than Suspend when the method is
> > > available.
> >
> > Continuing the slight tangent from earlier - why was this preferred to
> > hybrid-sleep, given that systemd apparently implements hybrid-sleep?
> > Off the top of my head I can think of only one tiny benefit of suspend-
> > then-hibernate over hybrid-sleep: after 3 hours it doesn't drain the
> > battery at all any more. Is that really a big enough benefit to
> > outweigh the drawback of *always* requiring the slower, much-more-
> > likely-to-fail 'resume-from-hibernation' behaviour after 3 hours or
> > more?
>
> hybrid-sleep would also seem to address the "hibernate *sometimes*
> works, but not often enough for us to support it or default to it"
> problem quite nicely...because it only uses hibernation as a last
> resort, when power is completely drained so resume from sleep is no
> longer possible. Think about it this way, we have three choices:
>
> 1) simple 'suspend': always uses the more reliable mechanism *unless*
> you lose power, at which point you have DEFINITELY lost your system
> state
>
> 2) suspend-then-hibernate: always uses the more reliable mechanism for
> three hours, then *ALWAYS* falls back to the less reliable mechanism.
> Will be substantially more risky than 1) for any case where the system
> sleeps for more than 3 hours, but retains power. Will only be safer
> than 1) when the system sleeps for more than 3 hours, then loses power.
>
> 3) hybrid-sleep: always uses the more reliable mechanism *unless* you
> lose power, at which point it gives the less reliable mechanism a shot.
> If it works, great! If it doesn't, you are no worse off than under 1).
> 2) has no advantages over 3) either, so far as I can see, except that
> if you sleep for a really long time and 'hibernate' actually happens to
> work on your system, maybe you have a little more battery life left
> when you resume.
>
> I don't see how 3) isn't the winner there, assuming the implementation
> is good.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> _______________________________________________
> desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
