On Fri, Sep 14, 2018 at 8:18 PM, <mcatanzaro(a)gnome.org> wrote:
On Fri, Sep 14, 2018 at 6:47 PM, Chris Murphy
> 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