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(a)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 <bberg(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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