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
