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. Benjamin
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
