Re: Disable (or make configurable and default to off) suspend-then-hibernate behavior in GNOME-3.30

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Fri, Sep 14, 2018 at 8:18 PM,  <mcatanzaro@xxxxxxxxx> wrote:
> On Fri, Sep 14, 2018 at 6:47 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
> wrote:
>>
>> I think it's just as problematic if the system is under memory
>> pressure without sufficient swap, the kernel invokes OOM killer. My
>> experience with OOM killer is in the realm of "ok so why don't you
>> just kill...oh nice there goes sshd...I'm screwed" rather than killing
>> firefox or chrome. I haven't dug into any of the logic the OOM killer
>> is using, or whether it's configurable. But yeah top on my list of
>> things to kill is the web browser because it has a session restore :-)
>> and tends to be the biggest memory pig on the system by far.
>
>
> Is that really worse? Thing is, when Fedora Workstation starts swapping, the
> user loses control of the desktop and the only practical solution is to hold
> the power button. Hard to imagine losing random processes would be worse
> than that. (Let's not optimize for sshd; this is Workstation after all.)

OOM killer might be worse if it's really arbitrary or
non-configurable. What if it kills PackageKit, or gvfsd, or the
journal? A sluggish system to the point it's unusable is bad, but it's
probably less bad than services silently dying. Anyway, both are bad.

But also, my laptop has NVMe. When swap is NVMe backed, it's
tolerable. And zswap moderates the performance drop well enough that I
get a heads up to make adjustments.

The one instance I've hit memory pressure and hit the power button?
Workstation Live in a VM with 1500MB RAM (which is 50% more than the
minimum on the download page), it has no swap setup, and I almost
immediately get the OOM killer upon launching the installer. Whereas
if I activate swap to even a hard drive, it's tolerable even if slow.
Way better than that is 'systemctl start zram' which runs a
zram.service item included with the anaconda package, and it sets up
swap backed by a zram device. This service is enabled by default on
netinstalls but not Lives. I don't know why.


> We handle swap really, *really* badly. I'm inclined to think that if we want
> to keep it, this situation needs to dramatically improve to guarantee that
> desktop interactivity isn't compromised.

The anaconda zram.service works well for installation environments. I
haven't tested it for day to day.

I think the IoT folks are making swap on zram enabled in their default
installation. Makes sense, there's a good way to cook eMMC quickly and
it's swap.


-- 
Chris Murphy
_______________________________________________
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




[Index of Archives]     [Fedora Users]     [Fedora KDE]     [Fedora Announce]     [Fedora Docs]     [Fedora Config]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux