Re: earlyoom by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Mon, Jan 13, 2020 at 10:51 AM Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote:
> On 1/8/20 5:21 PM, Chris Murphy wrote:
> > On Mon, Jan 6, 2020 at 7:56 PM Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote:
> >>
> >> For cloud at least it's very common to not have swap. I'd argue for servers
> >> you don't want them swapping either but resources aren't quite as elastic as
> >> in the cloud so you might not be able to burst resources like you can in the cloud.
> >
> > There's also discussion about making oomd a universal solution for
> > this; but I came across this issue asserting PSI (kernel pressure
> > stall information) does not work well without swap.
> >
> >
> > Ignoring whether+what+when a workaround may be found for that, what do
> > you think about always having swap-on-ZRAM enabled in these same
> > environments? The idea there is a configurable size /dev/zram block
> > device (basically a compressible RAM disk) on which swap is created.
> > Based on discussions with anaconda, IoT, Workstation, and systemd
> > folks - I think there's a potential to converge on systemd-zram
> > generator (rust) to do this.
> >
> >
> > Workstation wg is mulling over the idea of dropping separate swap
> > partitions entirely, and using a swap-on-ZRAM device instead; possibly
> > with a dynamically created swapfile for certain use cases like
> > hibernation. So I'm curious if this might have broader appeal, and get
> > systemd-zram generator production ready.
> >
> Seems like an interesting concept. Since it doesn't require any disk setup
> it's easy to turn it off or configure it I assume.
> +1

Yes. My suggestion is to install this generator distribution wide. The
on/off switch is the existence of a configuration file. If there's no
config, the generator is a no op. And it won't run in containers

Next, the discussion is whether the distribution default is with
config, or without config. Either way it's overridable.

I think a reasonable universal default would be something like a
zram:RAM ratio of 1:2 or 1:1. And cap it to somewhere around 2-4G.

The rationale:

- Fedora IoT folks use swap on zram by default out of the box (via
zram package, not this zram-generator) for a long time, maybe since
the beginning.

- Upstream zram kernel devs say it's reasonable to go up to 2:1
because compression ratios are about 2:1, but it's pointless to go
above that. Therefore 1:1 is quite conservative. 0.5 is even more
conservative but still useful

- 1:1 is consistent with existing defaults (Anaconda, anyway)

- The cap means systems with a lot of RAM will only use it
incidentally. Any time swap thrashing happens with traditional swap is
IO bound, but becomes CPU bound on a zram device (because of all the
compression/decompression hits). So making it small avoids too much of

- Considers upgrade behavior, where existing traditional swap on a
partition is being used; create the swap on zram device with a high
priority, so it's used first.

Chris Murphy
cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
List Guidelines:
List Archives:

[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux