> 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 вт, 14 июл. 2020 г. в 17:19, Benjamin Berg <bb...@redhat.com>: > On Mon, 2020-07-13 at 19:25 -0600, Chris Murphy wrote: > > On Mon, Jul 13, 2020 at 12:00 PM Benjamin Berg <bb...@redhat.com> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
