-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Tue, 2020-07-14 at 01:28 +0900, Alexey A. wrote:
> 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.
Please open ticket upstream with some more details, please.
пт, 10 июл. 2020 г. в 01:19, Chris Murphy
<lists(a)colorremedies.com>:
> On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter <rdieter(a)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(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
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8Mj3sACgkQEV1auJxc
Hh4y9w/9GujtHWfY2C2QDcUfSaFwkGIgQgBP4oN4LC2QUlQyyQNAbMk7Gtt9E1+M
1lGD+JqXJ4OD7yrTd9gDP/gKxu4Hto47Cqn8Hn4aP0uKMl7SGO4UmRVY1mTZRXEu
VJ+XlqDK+pnwIk4qxalLIJ0WVYrH3FcRCh9x8/KY83GiAka05hGqHJhS6R8tWnwE
PaAV1Mx86h5zcKKu1vz6rUNBVGZDb+v0qd0b/9F5QcxYmCzrTvjhBoV2fRhP/Etp
z8KTm+IKN+fWZULuJg3Cj8iMJxa6MLvteo3NakPERf34JuytyaUHfbrS0TeyOqGi
BaqQwPiMAOZcSVQRhHoGW1NCCvQeapHLxvNG870S4dHiCdpUgHnPlX+JxqooX0/A
aXdP6TkhCNizEnKcmmRdo5+j9na+dfzWktvQEeiGu2kJ9LPMzb9x4x0XgiBjPyNb
G6BTCA7RA1dJRdEuqJfOCaZ9RGqgTlWR4yzbIT8o8LbP2JGgfeoEHlv7+3tOQ6ZV
mhJkiA02EFTYcdI3p+SXNHLYc6woQWDLXOcIY7akOto6/+B8MGjhCzequxg1Qbya
pWhQweA4JtwLSN1L0suLI8gKR8KEQakpN+1706BJoEHBFWz8tBitRthT22FL1XTK
1AqBEELoAWrRIaqGF1FpFW4NHKdM5FFbB8MgEx2dxti/L9waAPE=
=0eBP
-----END PGP SIGNATURE-----