> And this will turn bad quickly, as it will eventually
> include the executables/libraries that must be loaded as they are doing
> work!
> So, we don't want to get the kernel into the situation where it must
> remove executables/libraries from main memory. If that happens, you can
> end up hitting the disk for *every* function call.
BTW, with prelockd[1] executables/libraries will not be removed from memory. This daemon can mlock executables/libraries in memory.
Effects:
- OOM killer comes faster.
- Fast system reclaiming after OOM.
This daemon was written recently, published today.
1. https://github.com/hakavlad/prelockd
> include the executables/libraries that must be loaded as they are doing
> work!
> So, we don't want to get the kernel into the situation where it must
> remove executables/libraries from main memory. If that happens, you can
> end up hitting the disk for *every* function call.
BTW, with prelockd[1] executables/libraries will not be removed from memory. This daemon can mlock executables/libraries in memory.
Effects:
- OOM killer comes faster.
- Fast system reclaiming after OOM.
This daemon was written recently, published today.
1. https://github.com/hakavlad/prelockd
вт, 14 июл. 2020 г. в 17:19, Benjamin Berg <bberg@xxxxxxxxxx>:
On Mon, 2020-07-13 at 19:25 -0600, Chris Murphy wrote:
> On Mon, Jul 13, 2020 at 12:00 PM Benjamin Berg <bberg@xxxxxxxxxx> wrote:
> > If MemAvailable drops below 250MiB (roughly 6GiB * 4%), then this means
> > that we have less than 500MiB left for file caches. If we can't swap
> > (remember, swap is already pretty full too), then a big chunk of these
> > caches need to be dropped to make the memory available to applications.
>
> I regularly see impressively low MemAvailable before earlyoom does
> SIGTERM, it's almost always swap available (amount of total that's not
> used) that's the defining factor. Well below 100MiB. This doesn't tend
> to last very long. Once memory is under this kind of pressure, so is
> swap, and as swap on zram is so fast, it gets to threshold fast as
> well.
Yep, EarlyOOM doesn't apply the limit if there is swap available. That
makes a lot of sense. When swap page is available, the kernel has the
choice which memory to reclaim (anonymous pages, i.e. swap, or file
backed pages, i.e. drop caches). So MemAvailable may drop much lower
temporarily and depending on the workload.
You could say that when swap is available you assume the kernel has the
ability to keep the system running reasonably well. Once swap runs out,
the kernel stops having a choice. It can only make room by reclaiming
important caches. And this will turn bad quickly, as it will eventually
include the executables/libraries that must be loaded as they are doing
work!
So, we don't want to get the kernel into the situation where it must
remove executables/libraries from main memory. If that happens, you can
end up hitting the disk for *every* function call.
Benjamin
_______________________________________________
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
_______________________________________________ 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
