@juliank noted I’d done a bit of research on this for the Pi images, and is correct in saying I did switch zswap on by default for the Pi desktop images (note: not the Pi server images), so I’ll weigh in with my current thoughts (prior thoughts are available 1).
On zswap vs zram, I think the debate is fairly settled there (thanks to @tobhe for posting some informative links): zswap is generally superior, and zram should be considered only if you don’t have any appropriate backing store for physical swap.
For me, the two questions that need answering are:
-
Should we enable zswap by default?
-
If so, what settings should be enforced by default?
1. Should we enable zswap by default?
Firstly, a crucial point that is often misunderstood, and I think is important when considering question 1: both zswap and zram reduce physically available RAM. Yes, overall they increase the amount of virtual memory available for the system to stick pages into, but both allocate some percentage of the physical RAM to do so. On systems with 8GB (or more) of RAM, reserving (for example) 2GB for compressed swap storage is a reasonable trade-off. However, the smaller the physical RAM, the riskier this becomes.
Consider the case of the Raspberry Pi Zero 2W (one of the platforms we support). This has 512MB of physical RAM. The graphical sub-systems reserve 64MB of that (by default), and with all the default stuff we run on the server image, at runtime there’s often no more than 250MB (ish) of available physical RAM left. If we reserve 20% of physical RAM (~100MB) for zswap we easily put the machine at risk of not being able to run basic processes like unattended-upgrades (apt can eat quite a lot of RAM, at least from the perspective of a little Pi, during dependency resolution).
This was one of the considerations behind only enabling zswap on the Ubuntu’s Pi desktop images. There, the minimum RAM we support is (currently) 4GB so we can reasonably assume machines have at least that much. The desktop images also construct a swap-file by default, so zswap is an excellent choice.
The choice for server images is much harder to make:
-
The range of hardware supported is far greater, going all the way down to the truly tiny like the aforementioned Zero 2W.
-
The environments involved are also far more diverse, including systems that boot entirely from network storage (where we need to consider whether running swap over networked storage is a sane idea).
-
I also judge that a typical server admin is much more likely to be capable of customizing their installation to enable zswap if they desire, and deem it a good choice for their system (a typical desktop user is less likely to be comfortable fiddling with kernel command lines, in the general case, he says, trying not to cast aspersions on desktop users :-).
I think these arguments also apply to the non-Pi images; some miniature PCs and other SBCs also have very low-memory specs. Hence, my suggested answer to question 1, should we enable zswap is: “probably yes on images built from a desktop seed, probably no on all other images”.
2. What settings should be enforced by default?
Onto question 2, @marek-suchanek’s post provides some interesting points. Personally, I don’t think we can apply something as aggressive as a 40% pool size by default. However, the compressor question (lz4 vs zstd) is worth pondering.
Personally I would favour zstd. I acknowledge it causes a far greater performance impact when the machine is loaded. However, on a low-spec system where this will make the most difference, one is used to a certain amount of “performance disruption” anyway (my desktop is a Pi, ask me how I know :-), and if our primary goal here is maximising available memory to the platform, why not pick the option the makes the most impact on that.
Maybe maximising memory isn’t the primary goal, maybe it’s to have a responsive desktop? I can certainly see the argument for lz4, and I could easily be convinced that on larger systems it’s the right choice. But on smaller systems the debate between lz4 and zstd may be the choice between being capable of running something and incapable of running it. To put it another way, “more capable, less responsive” vs “less capable, more responsive”. In that case, again, I’d have to side with zstd.
@eeickmeyer’s points about Ubuntu Studio are also well made: it’s very likely that a flavour with a specific intention (like Studio) may come to entirely different conclusions (and require different defaults). Whatever decision is made must be easily customizable for the flavours.
Installer possibilities
What about customization based on installed memory size? If the installer can measure physically available RAM, perhaps we could vary the parameters (or even activation) based on this? We could avoid zswap entirely on systems below 4GB, used zstd on systems below some threshold, and lz4 on systems above it?
That brings up additional questions of whether querying physical RAM is always accurate, do we have a mechanism of customizing the kernel cmdline via the installer, etc. etc. (the Pi images are pre-installed, so my knowledge of the installer is extremely limited – I leave it to others to ponder these questions!).
Closing thoughts
I do think the case for enabling zswap on the desktop images is good, but is it too late to make the change for resolute?
We are past feature freeze after all, and I’m not sure experimenting with things like this is a good idea in an LTS anyway. There’s a reason I originally made this change for the Pi images in Hirsute: I wanted to try it in an interim and see if it was a good idea to keep it in the forthcoming Jammy LTS. I would suggest this should be something to seriously consider for RR+1? If it works well in an interim, maybe we could SRU the change for an RR point-release following the interim?
Anyway, that’s my 2¢ (and change!). For Resolute, the Pi desktop images will continue to use zswap with zstd (as they have since Hirsuite), and the Pi server images will continue without zswap (leaving it to the server admin to choose how they configure their system).