Make algorithm_params configurable

[LiviaMedeiros]

In the modern kernels we have write-only /sys/block/zram<id>/algorithm_params files that can accept additional parameters for the selected algo, for example:

echo "algo=zstd level=8 dict=/etc/dictionary" > /sys/block/zram0/algorithm_params

Most notably, it allows us to set the compression level to achieve lower CPU load or better compression ratio.
Setting the params must be done before initializing the zram device (i.e. before setting disksize).

It would be great to be able to set something like

para3="level=22"

in the zram-init config.

Refs: https://docs.kernel.org/admin-guide/blockdev/zram.html#set-compression-algorithm-parameters-optional, https://lore.kernel.org/linux-block/[email protected]/

[vaeth]

I have not tried, but all shell-scripts involved in zram-init should be correct with spaces (that is, I would consider it a bug if they are not). In particular, it should not be a problem to do something like -a "zstd level=22" or algo0="zstd level=22".

[LiviaMedeiros]

I don't think this would work. The -a parameter is passed as --algorithm to zramctl, and it just directly controls the comp_algorithm attribute: https://github.com/util-linux/util-linux/blob/139980a5969bf851feda873fe918f34bee8fc055/sys-utils/zramctl.c#L794-L796
What should be added is control over algorithm_params attribute, which is separate from comp_algorithm and AFAICT isn't supported by util-linux yet.

[vaeth]

I see; I got confused, because of the term zstd in the parameters (actually, I do not understand why this has to be repeated: Are these parameter supposed to be used instead of comp_algorithm).

I tagged the new version temporarily with 12.0 (this is not yet an official release) so that you can easily download. I would appreciate if you could test it if you have a corresponding kernel. (If it does not work, I will re-tag 12.0 once I got a working version.)

[LiviaMedeiros]

I see; I got confused, because of the term zstd in the parameters (actually, I do not understand why this has to be repeated: Are these parameter supposed to be used instead of comp_zstd).

I'm not quite sure why this attr accepts algo parameter and does it override comp_algorithm (perhaps thoughtful reading through drivers/block/zram/* logs might give an answer), but this parameter is optional anyway.

I tagged the new version temporarily with 12.0 (this is not yet an official release) so that you can easily download.

Thanks! I'll test it on gentoo with unpatched v6.12.2 kernel tomorrow.
The code in 0e2211a is mostly LGTM. I was preparing PR with similar changes but then realized that it should be supported on zramctl side so we can avoid writing to file and weird command order (not sure if setting algorithm_params before comp_algorithm is appropriate). I've opened util-linux/util-linux#3313 to address that; if it gets accepted, we'll be able to do something like

	zramctl --size "${size}MiB" \
		${streams:+--streams "$streams"} \
+		${params:+--params "$params"} \
		${algo:+--algorithm "$algo"} ${1+"$@"} \

I'll make a PR with a few fixes now.

[vaeth]

Fixed in (re-tagged and released) v12.0. Please ping me or re-open when util-linux gets updated.

[LiviaMedeiros]

I've confirmed that after patching #45 the parameters are successfully configurable. 🎉
Tested on freshly mounted /tmp with /usr/src/linux-6.12.3-gentoo copied there.

$ zramctl /dev/zram0 # default (implicit level=3)
NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd           16G  2.1G 511.9M 525.7M       4 /tmp
$ zramctl /dev/zram0 # level=1
NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd           16G  2.1G 524.5M 538.7M       4 /tmp
$ zramctl /dev/zram0 # level=22
NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd           16G  2.1G 475.5M 488.8M       4 /tmp

Also, unrelated to this issue, but on lvl22 I had time to observe something strange: even though there was maxs0=2 in /etc/con.f/zram-init and zramctl reported TOTAL STREAMS 4, compression was done in single thread. The system also refused to sudo reboot until compression was completed.