On Mon, Jan 6, 2020 at 4:57 AM Roberto Ragusa <mail(a)robertoragusa.it> wrote:
On 1/5/20 12:38 AM, Chris Murphy wrote:
> On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova <alpha(a)bookwar.info>
>> Since in the Change we are not introducing just the earlyoom tool but enable it
with a specific profile I would add those details here. Smth like:
>> "earlyoom service will choose the offending process based on the same
oom_score as kernel uses. It will send a SIGTERM signal on 10% of RAM left, and SIGKILL on
> I add this information to the summary. Also, I think these numbers may
> need to change to avoid prematurely sending SIGTERM when the system
> has no swap device.
I read that sentence in a different way:
"earlyoom will make only 90% of your RAM available,
so it is effectively using 10% of your RAM".
On my 32GB laptop that means 3.2GB of RAM gets unusable.
And on my 64GB machine I'm being robbed of 6.4GB. Wow.
How low can these numbers be pushed? Even 3% would be 1GB out of 32GB.
What you say is only true in the case of systems with no swap. That's
mentioned in the proposal. If swap is being used, for sure essentially
all of your RAM is being used, so it's swap that's the determining
factor. If you don't have swap, yes RAM becomes the determining factor
and I agree that on systems with a lot of RAM, 10% is too high.
The ideal scenario is to not run earlyoom at all on systems that do
not have a swap device. They're not going to run into the responsivity
problem anyway, which is a direct consequence of heavy swapping.