Hello Stefan and sorry for the late reply, Stefan Baums <ba...@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
