Chris Murphy <lists(a)colorremedies.com> writes:
Robbie Harwood <rharwood(a)redhat.com> wrote:
> "John M. Harris Jr" <johnmh(a)splentity.com> writes:
>> On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote:
>>> Robbie Harwood <rharwood(a)redhat.com> writes:
>>>> Ben Cotton <bcotton(a)redhat.com> writes:
>>>>> == Summary ==
>>>>> Install earlyoom package, and enable it by default. This will cause
>>>>> the kernel oomkiller to trigger sooner, but will not affect which
>>>>> process it chooses to kill off. The idea is to recover from out of
>>>>> memory situations sooner, rather than the typical complete system
>>>>> in which the user has no other choice but to force power off.
>>>>> # enable earlyoom by default on workstation
>>>>> enable earlyoom.service
>>>> The OOM killer is a kernel function. I have no opinion on this proposal
>>>> as it stands, but I would like it to include an explanation of why this
>>>> requires a service in userspace to fix.
>>> Another thought. Wouldn't some of the pain here be alleviated by
>>> setting vm.swappiness=0? Currently it seems to be 60, which results
>>> in somewhat aggressive swap use; 1 seems better (minimal swapping
>>> without disabling), while 0 will disable it for general use (while
>>> preserving it for hibernation). This would at least improve the disk
>>> thrashing during OOM situations.
>> To clarify, according to the Workstation group, hibernation isn't even
> If that's true - and I don't know how I'd check it, so I didn't - we
> should revisit enabling swap in the default install, and *definitely*
> should remove the warning for not having it from anaconda.
It's not correct that the Workstation working group doesn't want to
see it supported, it's a question of whether and to what degree it can
be supported, and making sure users have expectations proper set. I
wouldn't want users thinking it'll work by advertising that it does,
and then it eats their data.
I think enabling it by default very strongly suggests it's supported,
regardless of what the intentions are. I have no quarrel with the
kernel team in either direction they wish to decide (supported or non),
but if it's non-supported, it shouldn't look like it's supported.
As for swap size options including no swap, and maybe swap-on-ZRAM:
There are all kinds of useful and necessary discussions to have there
(rather than here).
The links are appreciated; I was not aware of these discussions and will
follow them. However, since we're discussing behavior of the system
under heavy load, I think how we handle swap (the thing that makes it
slow down when you're low on memory...) is extremely relevant.