> The most
> common value I've found over a long period of time, for swap without
> hibernation is 50% of RAM.
With low RAM (2G) it's easy to use swap on zram with disksize = 150% MemTotal with opening browsers.
50% maybe OK with MemTotal=8G.
> I'd like to hear from Alexey what he thinks about further reducing the
> values in earlyoom versus possibly raising the cap in
> zram-generator-defaults.
It may be OK to reduce mem cap to 200 MiB. This threshold also can work well and may be sufficient to prevent freezing.
I would suggest to increase zram disksize caps up to 75% and maybe to 6GB.
> common value I've found over a long period of time, for swap without
> hibernation is 50% of RAM.
With low RAM (2G) it's easy to use swap on zram with disksize = 150% MemTotal with opening browsers.
50% maybe OK with MemTotal=8G.
> I'd like to hear from Alexey what he thinks about further reducing the
> values in earlyoom versus possibly raising the cap in
> zram-generator-defaults.
It may be OK to reduce mem cap to 200 MiB. This threshold also can work well and may be sufficient to prevent freezing.
I would suggest to increase zram disksize caps up to 75% and maybe to 6GB.
пт, 10 июл. 2020 г. в 01:19, Chris Murphy <lists@xxxxxxxxxxxxxxxxx>:
On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter <rdieter@xxxxxxxxxxxx> wrote:
>
> part of some irc discussions on
> https://fedoraproject.org/wiki/Changes/KDEEarlyOOM
>
> raised my attention to related item,
> https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>
> As it stands currently with earlyoom, it's default thresholds are 4% ram and
> 10% swap before it acts. That's fine and dandy.
>
> Upon reading the SwapOnZRAM feature proposal, I see it is advocating
> allocating 50% of ram for swap. I'd like folks to consider and evaluate how
> this impacts earlyoom. It effectively makes the earlyoom memory threshold
> double (right?). If so, at least think about lowering 4 to (2 or 3), since
> that will make earlyoom's behavior closer to before swaponzram was
> introduced.
>
> Thoughts?
The net effect is that earlyoom is more likely to trigger than with a
disk based swap because right now disk based swap is huge by default.
It's huge by default to accommodate a hibernation image. The most
common value I've found over a long period of time, for swap without
hibernation is 50% of RAM. So this approximates those expectations.
I'd like to hear from Alexey what he thinks about further reducing the
values in earlyoom versus possibly raising the cap in
zram-generator-defaults. I don't want to get too carried away there,
because we are applying this to upgrades (wherever the to-be-obsoleted
'zram' package exists already even if not enabled). There is an
opportunity, of course, right now and through beta testing, to keep on
testing variations on both the size of the zram device used for swap
and for earlyoom. But we also have another Fedora release, Fedora 34.
So I'm more inclined to go conservative so long as that itself isn't
causing problems.
One thing I'm a bit skeptical of with reducing earlyoom's triggers is
that free memory is needed for the recovery from an actual kill.
Usually this is just sigterm. That's the first attempt. If that
doesn't work then earlyoom issues sigkill, which is at a lower
threshold already.
--
Chris Murphy
_______________________________________________
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
