long boot times with zram_count=16

[mabod]

I am using endeavourOS with systemd-swap 4.4.0-2.

Since the last update I experienced very long boot times of almost 2 min. For me it seemed to be related to the systemd update to 247.4-2. A similar issue is reported for systemd systemd/systemd#15316

The solution mentioned there is also working for me:

sudo pacman -S dbus-broker
sudo systemctl enable dbus-broker.service

But in the meantime I did more investigations and found that systemd-swap has something to do with it.

This is the config I used to use:

zram_enabled=1
zram_size=$(( RAM_SIZE / 8 ))
zram_count=${NCPU}
zram_alg=lz4

This creates 16 zram devices with 502 MB each. (64 GB of RAM)

Without dbus-broker I get very long start times like

48.988s systemd-swap.service

with dbus-broker enabled the start time is much faster.

3.805s systemd-swap.service

But if I set zram_count=1, which creates one zram device of size 7,9 GB. the start time is even faster even without dbus-broker:

1.659s systemd-swap.service

Why is that? What is the dependency to dbus-broker all about?

[vilgotf]

First thing, you should always use only one zram device since there's no performance improvement from having multiple (this should be documented). Secondly I'd recommend systemd/zram-generator if you only use zram (should also be documented).

I'll keep this issue in mind, but don't expect any patches soon.

[mabod]

First thing, you should always use only one zram device since there's no performance improvement from having multiple (this should be documented).

That is interesting because the default behavior is actually that it creates ${NCPU} zram devices. I just tested it by commenting the zram_count in the config file. Shouldnt the default then be just one zram device?

And it does not explain where the dependency to dbus-broker is coming from: 49 s without dbus-broker compared to 4 s with dbus-broker is a big difference.

[HidingCherry]

Please read this:
https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#set-max-number-of-compression-streams

Since we have multiple streams per zram device - there is no use to have multiple zram devices.
An exception might be with multiple NUMA devices? Although - I don't know if the kernel takes this into account.

[polarathene]

The referenced systemd issue got resolved, bug was identified as something missed during 2016 commit. PR was merged recently for upcoming v251 release of systemd.

dbus-broker avoided the issue as it doesn't try to do some logic that dbus-daemon was doing (which IIRC was timing out from a deadlock or something like that), dbus-daemon also queues messages differently I think, so your experience with multiple devices vs single was likely related to behaviour with that?

Should be safe to close issue? (unless you want to wait for v251 release and broader availability)

[mabod]

From my point of view it can be closed. Thank you!
But can you share a link to the systemd PR here?

[polarathene]

can you share a link to the systemd PR here?

systemd/systemd#22552