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. > > 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 _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/cloud@xxxxxxxxxxxxxxxxxxxxxxx
