Short term? Stop using a ratio to determine swap size at 24G RAM, and instead create 4G swap. (Paper napkin approach.)

Medium term? It would be useful to poll our target market, filtered for custom partitioning. How do they use their computers, and what's their setup preference that matches that workload? How do they use laptops differently from workstations? Swap is really a policy related to workload, and likely not well suited to being a partition time decision. Having real world data would help decision making here, but perhaps also ZRAM vs zswap and default partitioning.

Point of comparison: Since ancient times Windows and macOS dynamically allocate swapfiles. We could do that too, but it needs a longer term approach to build a prototype and benchmark it, see if it's worth the effort to deploy and maintain. For example:

Lennart floated an idea on devel@ (a thread directly related to #98, with the same title) of a systemd unit, that can create swapfiles on demand; even create a hibernation file at hibernation time, that way it's possible to hibernate, but also such a huge file isn't used for swap purposes. This could use the kernel's pressure stall information (PSI) to dynamically allocate swapfiles. i.e. if adding another swapfile helps performance, create it; if it's making things worse, don't create more.

On a workstation-class machine with 64 GB RAM, it creates a 64 GB swap partition

This is not bad with zram: such swap space does not take up disk space. The problem will be resolved when setting the swap to zram by default.

For example, I have 20 GB zram disksize and 10 GB MemTotal, and I have no problems with that.

Yep. @hadess proposed this some months ago:
Default to no disk swap for Workstation installations (anaconda)
https://bugzilla.redhat.com/show_bug.cgi?id=1731978

I pinged #anaconda folks about this wg issue, to join in this discussion.

Maybe start a Taiga kanban for this? Some of the issues:
a. anaconda: no swap partition by default
b. hibernation: decision
c. fc33 change proposal
d. get systemd-zram generator production ready, packaged for Fedora, installed and enabled by default (enabling only requires a conf file to exist, if it does not exist, swap-on-zram isn't setup) in all Fedora outputs
https://github.com/systemd/zram-generator
e. anaconda: should not use its own zram setup on fc33+
f. tuning (zram size: fixed or ratio, compression algo)
g. upgrade outcome (two swaps?)

I think it can happen for fc33 but depends on resources for mainly a, d and e. The net of this probably needs a change proposal.

What we have to take into consideration is that user could always create a swap. We can't and we don't want to block that in Anaconda. So all the solution above should think about both variants. With and without swap.

Also, wouldn't it be better to use the generator and skip the temporal solution? It would save some work for everyone. How long it may take before the generator will be production ready?

@jkonecny I definitely think the generator is better, just include it distro wide, and deprecate the other implementations. I guess the first step is recruitment for someone to package up and maintainer the generator.

Understood that the user could always create a swap partition in anaconda, or after-the-fact, and also upgrade behavior needs to be considered. Setting up the /dev/zram device uses almost no memory, it's not a reserved space, it only starts to use RAM as the swap device is used. Also, we can make the priority of the zram device high enough that it will be used first, with spill over happening on a conventional swap partition. Multiple swaps is supported by kernel code since forever.

The "systemd-zram generator" should already be packaged and working as "zram-generator". I haven't had the chance to test it since keszybz fixed it.

@hadess Awesome! It works!

@hadess I've filed some issues upstream. Issue 7 and 8 I think need attention to enable it by default in Workstation.

Looking back to #98, it originally proposed swap on zram and dropping disk based swap; and @ignatenkobrain suggested this would be a self-contained change, unless I misunderstood something, and the deadline for Fedora 32 self-contained changes would be 21 Jan (one week from now).

Should we make the attempt for F32? Or push it off to Fedora 33? If F33, I'm more confident it would be a system-wide change, and coordinate the defaults with the various other editions/spins.

I suggest F33 system-wide change, but we try to land the change ASAP after F32 is branched. The longer we have to test a change like this, the better.

Reducing swap partition to 2-4G, or eliminating it entirely (in favor of swap on ZRAM) means hibernation cannot happen with default partitioning. Suggests #121 blocks this issue.

@jkonecny please consider joining our next meeting, 25 Feb @ 1430 UTC, and/or anyone else on the Anaconda team.

Agenda and joining information.

Specifically the last item on the agenda related to Workstation WG issues #120, #121, #127. At the moment I can't estimate the start time for this item, but if you like I can ping you on #anaconda when we're about ready?

• The proposal applies to Workstation installations using the default/automatic partitioning path only, and aims to not create a swap partition, and use systemd/zram-generator instead.

• Gist is to change pyanaconda/modules/storage/partitioning/automatic/automatic_partitioning.py to no longer create a swap partition; and to add /etc/systemd/zram-generator.conf as appropriate.

• Is it possible and desirable to also affect Custom>Scheme drop down menu "presets"? i.e. cause those presets, on Workstation install media, to not create a swap partition? Of course, users can manually add a swap partition.

Thanks for the invite. We will join you on the meeting.

Proposals for the 3 Mar meeting:

1. Drop the creation of swap partition for Fedora Workstation 33.
2. Drop the creation of swap partition for Fedora Workstation 33, contingent on one of the swap-on-ZRAM implementations being production ready replacements.
(refined below)

Just to clarify things. We will still preserve hibernation and everything if user will manually create swap partition during the installation.

Just to clarify things. We will still preserve hibernation and everything if user will manually create swap partition during the installation.

@jkonecny Understood and it's completely reasonable.

Proposal 1: the edition will have a small swap partition[1], ~4GiB, created at install time.
Proposal 2: the edition will not have a swap partition[1] created at install time.

Explanation: reason why we may still want to create a small swap partition:
a. testing of ZRAM goes poorly, or
b. zswap progress goes well,
c. leaves us open to swapfiles.

It's possible to agree/consent to both. They contradict each other, but any ambiguity will be resolved once there's a status and testing report on ZRAM, zswap, or none of the above.

Agreement to both now means issues #120, and #121 can be closed; and issue #54 is slightly simpler.

[1]
swap partition = an MBR or GPT or LVM partition or swapfile on an SSD or HDD for the purpose of mkswap→swapon.

Proposal 1: the edition will have a small swap partition[1], ~4GiB, created at install time.
Proposal 2: the edition will not have a swap partition[1] created at install time.
Explanation: reason why we may still want to create a small swap partition:
a. testing of ZRAM goes poorly, or
b. zswap progress goes well,
c. leaves us open to swapfiles.
It's possible to agree/consent to both. They contradict each other, but any ambiguity will be resolved once there's a status and testing report on ZRAM, zswap, or none of the above.

I don't think 1 makes sense. 4GB is still ~ the amount of RAM for a wide selection of devices, and a "dangerous" amount of storage space should it ever get used more than a little.

It needs to be 2. or status quo.

Agreement to both now means issues #120, and #121 can be closed; and issue #54 is slightly simpler.
[1]
swap partition = an MBR or GPT or LVM partition or swapfile on an SSD or HDD for the purpose of mkswap→swapon.

Sorry Bastien, that ~4GiB swap should be a cap. So it would not be bigger than 1:1 with RAM, but cap at 4GiB.

4GiB swap should be a cap. So it would not be bigger than 1:1 with RAM, but cap at 4GiB.

Sounds good (in fact I think max size for HDD/SSD 4GB is good, but for with swap on zram I like 6-8 GB limit, because zram do not occupies disk space).

In today's meeting, the WG agreed in principle to both proposals, i.e. that the current swap partition is too big, that it should be made smaller or eliminated, and more specifics are required. WG needs:

• test results from issue#127
• recommendation that includes the specifics, e.g. sizes, upgrade handling
• a complete proposal(s) is preferred over the piecemeal/open-ended approach

Fixed this in #127 and
https://github.com/rhinstaller/anaconda/pull/2723/

Tested
Fedora-Workstation-Live-x86_64-Rawhide-20200715.n.2.iso