Re: SwapOnZRAM and how it affects earlyoom thresholds

2020-07-13 Thread Igor Raits
-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 :
> 
> > On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter 
> > 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

- -- 
Igor Raits 
-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-
___
devel mailing list -- 

Re: SwapOnZRAM and how it affects earlyoom thresholds

2020-07-13 Thread Alexey A.
> 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 :

> On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter  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


Re: SwapOnZRAM and how it affects earlyoom thresholds

2020-07-13 Thread Alexey A.
> Upon reading the SwapOnZRAM feature proposal, I see it is advocating
> allocating 50% of ram for swap

50% means zram disksize (max size of uncompressed data stored in zram
device) = 50% MemTotal. This data will be compressed, so, its size in RAM
will be smaller than 50% MemTotal (maybe 25% with 2:1 ratio).

> It effectively makes the earlyoom memory threshold
> double (right?).

I don’t understand why you think so.

I think that swap-on-zram proposal doesn't affect earlyoom behavior.

пт, 10 июл. 2020 г. в 00:49, Rex Dieter :

> 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?
>
> -- Rex
> ___
> 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


Re: SwapOnZRAM and how it affects earlyoom thresholds

2020-07-09 Thread Michael Catanzaro
On Thu, Jul 9, 2020 at 10:49 am, Rex Dieter  
wrote:

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.


Well it's min(50% of RAM, 4 GB). You never get more than 4 GB of zram.

___
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


Re: SwapOnZRAM and how it affects earlyoom thresholds

2020-07-09 Thread Chris Murphy
On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter  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


Re: SwapOnZRAM and how it affects earlyoom thresholds

2020-07-09 Thread Ben Cotton
On Thu, Jul 9, 2020 at 11:50 AM Rex Dieter  wrote:
>
> 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.
>
No objections from me as KDE EarlyOOM change owner. My main concern is
that if someone disables SwapOnZRAM, the effective default EarlyOOM
threshold changes. I don't think there's any easy way to handle that,
but it's an effect we should explicitly take into account.

With my FPgM hat on, I would consider this to be a part of the Swap on
ZRAM proposal, which has been approved by FESCo and so wouldn't
require its own change proposal.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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


SwapOnZRAM and how it affects earlyoom thresholds

2020-07-09 Thread Rex Dieter
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?

-- Rex
___
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