On Thu, 2020-07-09 at 07:51 -0700, John M. Harris Jr wrote:
> What's the KDE SIG's rationale behind supporting this? This actively limits 
> the amount of RAM that end users are able to make use of. The more RAM the 
> end 
> user has, the more RAM is not available for use, because EarlyOOM will kill 
> software long before it's able to be used. For example, on my system, with 6 
> GiB of RAM, this will send SIGTERM while I still have over half of a gigabyte 
> of RAM, and SIGKILL while I still have over a quarter of a gigabyte of RAM. 
> There's absolutely no justification for this, as I see it.

Sounds like you are misunderstanding the meaning of MemAvailable:

See https://www.kernel.org/doc/html/latest/filesystems/proc.html
An estimate of how much memory is available for starting new
applications, without swapping. Calculated from MemFree, SReclaimable,
the size of the file LRU lists, and the low watermarks in each zone.
The estimate takes into account that the system needs some page cache
to function well, and that not all reclaimable slab will be
reclaimable, due to items being in use. The impact of those factors
will vary from system to system.

It is more complicated than that. I believe that MemAvailable will
basically never reach zero. IIRC, it considers half of the memory
currently used for mmap'ed files to be reclaimable. So, for
MemAvailable to become as low as you are suggesting, you have most
likely already reclaimed major parts of the system. MemAvailable does
*not* imply that you can simply allocate that amount of memory and the
system will be fine.

So, you shouldn't be taking this number from the kernel at face value.
The kernel is also just second guessing here and simply does not really
know which memory is reclaimable and which is in active use.

> > 2.  It's clear you don't like this feature, but characterizing it as random
> >  and ruining things is going a bit far (to put it mildly).
> Not at all, see the above example. Most users have more RAM than I do, not 
> less, and even then, it's hurting the UX.

I don't think your above opinion is based on facts.


Attachment: signature.asc
Description: This is a digitally signed message part

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to