> 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. пт, 10 июл. 2020 г. в 01:19, Chris Murphy <li...@colorremedies.com>: > On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter <rdie...@math.unl.edu> 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@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
