On Mon, Jan 13, 2020 at 10:51 AM Dusty Mabe <dusty(a)dustymabe.com> wrote:
On 1/8/20 5:21 PM, Chris Murphy wrote:
> On Mon, Jan 6, 2020 at 7:56 PM Dusty Mabe <dusty(a)dustymabe.com> 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.
>
https://github.com/facebookincubator/oomd/issues/80
>
> 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.
>
https://github.com/systemd/zram-generator
>
> 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
regardless.
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
that.
- 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