Will Zram be enabled by default in 26.04?

Project Discussion Pre-Release Discussion
1

26.04 default zram on?

4 Likes
2

We should enable zswap for systems with swap enabled by default IMO; zram should not be in the picture.

5 Likes
3

That’d be fine in IMHO either way- I just think it’d be nice to have some standardized alternative to only hitting storage (and wearing on it) for swap. This would be especially nice in the current DRAM world of 2025-2026 where RAM isn’t as easy to come by.

4

Why?

Now, not for 26.04, but it may be useful in some contextes.

5

I think @waveform had a bunch of reasons to prefer zswap over zram and IIRC enabled it by default on Pi; I would prefer not to have two different stories around memory compression by default.

1 Like
6

Also interesting https://linuxblog.io/zswap-better-than-zram/ and https://discussion.fedoraproject.org/t/psa-transitioning-from-zram-swap-to-zswap/138256

1 Like
7

I’ve been thinking about this as well.

In my opinion, we should enable zswap on Ubuntu sometime after 26.04 LTS:

  • RAM prices keep increasing. We should effectively add more memory, not remove it. Therefore, we should keep the existing swap file and add compression on top.
  • If we already have a swap file or partition, zswap is more efficient than zram.

Then it becomes a matter of optimizing the zswap settings.

I want to suggest that we use the lz4 compressor. It’s comparable with lzo, having a slightly worse compression ratio but significantly better decompression speed: the decompression method is “able to reach RAM speed in multi-core systems”. That would mean loading compressed pages is practically as fast as with uncompressed pages.

I’ve also tried zstd with zswap. The compression ratio is much better but under heavy system load, when both your memory and your CPU are occupied, swapping pages with zstd causes noticeable stuttering on my laptop. With lz4, the absolute memory gains are worse but interactivity improves. For a desktop use case where you want to quickly switch between applications, lz4 provides a better experience in my opinion.

For comparison, Fedora currently uses zram with no on-disk swap and with the lzo compressor. Actually, lzo is the only suitable compressor for zram: specifically the lzo-lre (Run-length Encoding) implementation. It’s able to eliminate long series of identical values, which is common in memory. On the other hand, zswap implements this functionality at the zswap level, which makes the alternative compressors more competitive with zswap.

Choosing between lz4 and zstd might be a case of prioritizing latency or throughput. I’d vote for latency in this case because a stuttering desktop under heavy load is a qualitative change for the worse, while throughput that improves a little less than it could is only quantitative.

I suppose that a heavier compression algorithm, in theory, also drains the battery more quickly, compared to no compression or a lightweight algorithm. I haven’t done any tests, though.

I don’t know what the ideal size of the compressed memory portion should be, that probably depends on a lot of benchmarking.

To test these settings, add this configuration in your /etc/default/grub file in the GRUB_CMDLINE_LINUX_DEFAULT string:

  • Default size, lz4:

    zswap.enabled=1 zswap.compressor=lz4

  • Default size, zstd:

    zswap.enabled=1 zswap.compressor=zstd

  • Double size, lz4:

    zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=40

  • Double size, zstd:

    zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=40

Apply the configuration changes:

sudo update-grub2

And reboot.

3 Likes
8

So, with my Ubuntu Studio hat on, this has me thinking because any time latency or throughput enter the conversation, so does audio production. In audio production, the lower the latency the better, but throughput also needs to be maximized. I think on this, I’d err on the side of latency since anything that interrupts an audio stream can destroy a recording completely.

Now, the best practice here would be to not be in that situation entirely. Having enough RAM is ideal, but nowadays that is expensive and not all of us can afford to trick-out their machines with 1TB of RAM. Note the exaggeration; a well-configured audio production rig can get by with 16GB of RAM, 32 being a sweet spot, and 64GB being overkill in most cases while using a linux-based audio workflow.

But, I digress. I think keeping latency from increasing is best here.

1 Like
9

@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:

  1. Should we enable zswap by default?

  2. 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).

2 Likes
10

P.S. I’m aware both zram and zswap are capable of dynamic allocation of memory, but I’m considering the “fully loaded” scenario in the above post as that’s the case that’s going to be (increasingly commonly) hit in the low-memory spec cases

11

Thanks for the great points @waveform, I agree. Maybe we can limit the memory compression just to Desktop images and a few other, verified images. Choosing different settings for different amounts of memory seems rational.

Like you said, I do wonder how much we can detect at install time and if the installer is able to set the right configuration through kernel arguments. @dloose do you know if the installer is capable of that please?

The choice between the compression methods could also depend on how fast your storage is: if your disk is very slow, you might want to avoid swapping to it as much as possible, favoring zstd and its higher CPU usage. But storage performance is probably more difficult to detect than memory size, unless it’s enough to just distinguish between rotational (= “slow”) and non-rotational (= “fast”) storage.

The system properties can also change over time if the user adds more memory or changes the disk. I suppose it’s fine if the compression settings stay unchanged in that case, otherwise the system would have to reset them at every boot.

If we stick to the default compressed pool of 20% of your RAM, this could be the decision mechanism:

  1. Is there less than X (e.g. 2 or 4 GB) memory? ⇒ Disable memory compression.
  2. Is the installation target a rotational disk? ⇒ Enable zswap with zstd.
  3. Is there less than Y (e.g. 8 or 16 GB) memory? ⇒ Enable zswap with zstd.
  4. Otherwise ⇒ Enable zswap with lz4.

@eeickmeyer, if systems with at least 8 or 16 GB RAM used the “low-latency” lz4 compression, would that be an acceptable heuristic for Ubuntu Studio?

Regarding Ubuntu releases, I believe we should leave 26.04 LTS as is, and only experiment with this in 26.10 or later.

1 Like
12

I think so. We change the swappiness to avoid swap, but at times it can be inevitable, so I think that lz4 would be the way to go. Of course, we hope that it doesn’t happen in a recording session for anyone. That said, I think the benefits are worth it as long as latency is kept at a minimum, along with minimizing the thrashing that comes with swap which we already do by changing the swappiness.

2 Likes
13

An excellent article on this topic came out. Chris Down, a kernel developer working at Meta, compared zswap and zram in detail. His bottom line is:

If in doubt, prefer to use zswap. Only use zram if you have a highly specific reason to.

In practice, across the services we’ve deployed zswap on at scale, it has consistently reduced OOMs, cut disk write pressure, and done so without any manual intervention. zram is a completely manual part of the memory management subsystem – you take on the responsibility of managing it correctly, or you bear the consequences – whereas zswap is managed by the kernel itself, with all the live feedback, reclaim integration, and automatic tiering that entails. For the vast majority of Linux systems, you really want the kernel doing that work with zswap.

https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html

2 Likes