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

Re: F33: preview swap-on-ZRAM using zram-generator feature change



On Tue, Jun 2, 2020 at 9:47 AM Martin Kolman <mkolman redhat com> 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


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