bug#54783: ZRAM default priority wrong

[Josselin Poiret]

Hello Stefan and sorry for the late reply,

Stefan Baums <baums@stefanbaums.com> writes:

> The manual wrongly claims that the default priority for zram is
> -1. The same paragraph of the manual also says:
>
>    ‘swapon’ accepts values between -1 and 32767, with higher
>    values indicating higher priority.
>
> which makes the -2 priority of the swap file look suspect (though
> it seems to work).

This issue comes from the inconsistency with which swap priorities are
specified on Linux: `swapon` the binary from util-linux (man 8 swapon)
has roughly the same description as above, but internally uses the
syscall wrapper `swapon` from libc (man 2 swapon), which has a better
description of priorities.  The official interpretation of priorities
for the syscall is summarized in the "Swap space" part of the Guix
manual:

A swap space can have no priority, or a priority specified as an integer
between 0 and 32767.  The kernel will first use swap spaces of higher
priority when paging, and use same priority spaces on a round-robin
basis.  The kernel will use swap spaces without a set priority after
prioritized spaces, and in the order that they appeared in (not
round-robin).

Note that these are called high (for specified priority) or low
(unspecified) priority in `man 2 swapon` but that's a bit of a
misnomer.  So, `swapon` the binary actually maps -1 to no (low)
priority, and there actually is no -1 priority in the Linux kernel ABI!
Since your actual swap file is swapon'd first, and also has no priority
set, according to the rules above it will be used before the ZRAM which
also has no priority.

On the Guix side of things, we should really be using the same interface
as swap-space, as I think the distinction between #f and 0 to 32767 is
clearer.  I'll send some patches that adress this soon, along with the
zram-service-type documentation.

Best,
-- 
Josselin Poiret