On Tue, Jun 2, 2020 at 9:47 AM Martin Kolman <mkolman@xxxxxxxxxx> wrote: > > Back when ZRAM support was introduced in the installation environment the > aim was to enable installations and specially the more memory hungry graphical > installations on devices and VMs with less RAM. For devices with enough RAM > the installation could run just fine & ZRAM would be just extra overhead, so > we decided not to enable it here. > > This was quite some time ago (6/7 years ago) and things certainly changed, > making the ZRAM overhead very likely totally negligible on current systems. Upstream zram doc claims the overhead is 0.1% of the /dev/zram0 device size. e.g. ~64M/64G. In practice I haven't seen it use more than 0.04%, but perhaps it has some float as the /dev/zram0 device is actually being used, for tracking. In any case it's not much. I don't want the /dev/zram0 device to be too big by default, just in case some workloads have unexpectedly low compressibility, and I'd like to be conservative in order to ideally make it possible to apply it to upgrades. And perhaps in F34 with new clean installs, get a bit more aggressive if actual usage with F33 suggests it's a good idea. > > So I think dropping the conditions we have at the moment and simply always enabling ZRAM > with sensible configuration (like the IoT one mentioned above) should be fine. OK cool. > > > > > - Disable or somehow deprecate the Anaconda specific implementation, > > to avoid conflict and user confusion among the implementations. > IIRC we discussed using one of the scripts packaged in Fedora > (I think it was provided by systemd ?), ideally the one used by the other > tools that are part of this system wide change. We just have not did that > just yet. Yeah it's hard to find. In koji it's rust-zram-generator metapackage; but the actual command to try it out is 'dnf install zram-generator'. https://github.com/systemd/zram-generator > So I wonder if the image wide defaults change I guess it should be enough > if we coordinate dropping of our zram setup script at the same time the image > wide change is done ? Yes, I can help coordinate. I'll be doing the kickstart change to bring zram-generator and configuration file into the ISOs. Prior testing suggests two zram devices being created isn't a big deal, in practice they get different swap priorities, so only one will be used, there's just that 0.1% (or 0.04%) overhead for the unneeded extra /dev/zram device. Also it's not a preallocation. So if that scenario were to happen, it wouldn't cause openQA tests to face plant. The openQA tests I think are the most likely impacted, if there are two zram devices, since most of those VMs use 2G RAM and thus will trigger the anaconda implementation to also create a zram device. For most everyone else doing testing, they'll have more than 2G RAM for their VM or baremetal and are unlikely to run into this. Thanks! -- Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
