On Mon, Feb 10, 2020 at 4:12 AM Chris Murphy <lists(a)colorremedies.com> wrote:
Continued from the 'background and summary' email:
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...
Adding Hans and Matthew and Lennart to cc.
Questions I have are:
- WG is considering dropping creation of swap partitions by default,
in favor of swap-on-ZRAM. Any concerns? (We do know it's not possible
to use a ZRAM device for hibernation, but the kernel will look to
another swap device for contiguous free space to write out a
hibernation image.)
- What's the status of s2idle in the kernel?
- What sort of work is needed outside the kernel to properly support
s2idle, or is this predominantly kernel work? Microsoft documents on
Modern Standby suggest minimal application effort. [1]
A lot of the functionality is implemented in a non standard extension
to ACPI called PEP:
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-pe...
- Prospect of kernel support to separate swap and hibernation
partitions (and/or swap files)? Or systemd method of creating then
activating swapfiles on demand?
- Prospect of hibernation supported with UEFI Secure Boot?
- Is hibernation a better fallback than poweroff, given the
significant reliability differential? Why? Poweroff is universal,
hibernation isn't. What's the argument that a non-universally
available fallback is better than the universal fallback?
- What are the implications of hibernation if Fedora will move to
measured boot? (I'm not sure how mainstream that function is expected
to be, or it's use case specific opt-in.)
There's still a lot of work to be done there, but at least for IoT
we're looking at least being able to opt-in to this soon, I suspect it
will be quite a bit more work for something like workstation.
- There's some anecdotal evidence users are disabling UEFI
Secure
Boot, possibly quite a lot [2]. Does there need to be an effort at
making the signing of user built kernel and module easier? Can it be
made easier? I don't know custom or out of tree modules is a
significant motive for disabling SB, vs other explanations.
I don't think we have a break down between distros there, a lot of
distros such as Debian didn't support it until very recently, distros
like Gentoo and Arch still don't and so there's a lot of docs in those
communities where the first instruction is to disable it.
> - A systemd TODO makes me wonder: Does anyone have (corroborating)
> data on the reliability of firmware or battery reporting, when the
> system, and thus the battery, are under significant load? [3] I've
> discussed with a reliable source that on 2+ year old hardware, the
> vast majority of batteries are effectively broken and aren't likely to
> report anything reliably if they are under significant load, in
> particular waking from S3. By anything, I mean, time remaining, power
> remaining, and current power consumption rate. Would s2idle instead of
> S3 would make this more reliable?
>
> - It doesn't sound like S1 is really used at all, even though kernel
> docs say it's supported as shallow/standby. (?) Is it more or less
> reliable than S3?
>
> - I'm inclined to think we should mimic what hardware vendors,
> Microsoft, Apple, and Google (with Chromebooks and Android) have been
> doing for a while: faster boots, and S0 low power idle - and skip the
> things making devs and users crazy. But I invite a persuasive contrary
> argument.
>
> - Any other questions?
>
>
>
> [1]
>
https://docs.microsoft.com/en-us/windows-hardware/design/device-experienc...
> [2]
>
https://twitter.com/hughsient/status/1225826488903249920
> [3] see line "beef up hibernation"
>
https://github.com/systemd/systemd/blob/master/TODO
> --
> Chris Murphy
> _______________________________________________
> desktop mailing list -- desktop(a)lists.fedoraproject.org
> To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject...