On Sat, 2020-07-18 at 05:07 +0900, Alexey A. wrote: > > 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. Interesting, I had not seen that. I wonder how much memory that amounts to in the usual scenarios. Could be interesting to compare this to the point where EarlyOOM or similar would kick in. That said, I am sure that it is really effective at preventing many really bad thrashing scenarios. Benjamin > 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
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
