Hi, I'm providing answers to the questions which I believe I have some insight on below. On 2/10/20 5:11 AM, Chris Murphy wrote:
Continued from the 'background and summary' email: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx/message/V5MOCX23KU45J3WXUN6TCGEJYQLXQYUL/ 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?
It mostly works as a replacement for S3 suspend, but we do not really have support for tricks like keep playing music using a DSP to decode MP3 while keep everything else powered down (or keep e.g. a large download ongoing, etc.). These more advanced features are not really being worked on AFAIK.
- 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]
As "suspend" replacement no work is needed outside of the kernel, if want to move into the realm of "connected standby" then AFAIK work will be needed but what is needed has not been scoped out.
- 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 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.
The problem is that disabling secure boot is a lot easier then enrolling your own keys. Granted we could make generating and signing with your own key easier, but users still end up fighting with the firmware UI to get there own key enrolled. A better question is why are people disabling secure-boot (outside of people running there own kernels like me). Some possible answers outside of out control: 1) VirtualBox hypervisor kernel modules 2) nvidia binary driver The question is are there other reasons where we could do better so that people do not feel the need to disable secure boot?
- 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 don't think I've ever seen hardware where the ACPI tables claim S1 is supported. S1 and S2 were a cute idea when the spec was written, but in practice they are never used (AFAIK).
- 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.
Ack, as long as we are trying to run on hardware designed for Windows, the kernel-side answer to get things to work (atleast somewhat) reliable has always been figure out what Windows does and mimmick it. Note that a lot of work has been done on S0 low power idle support upstream, with recent kernels that should work reasonably well. Regards, Hans _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
