Hi,
These are based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso in a VM. The numbers are different on bare metal but correlate.
The only standout is rngd.service. That's a pretty big single hit, percentage wise. And I don't know if we even need it anymore. Among the rest, perhaps atd.service and crond.service could be disabled by default on new installations, in favor of systemd timers.
Startup finished in 1.320s (kernel) + 1.344s (initrd) + 7.727s (userspace) = 10.392s disable atd.service Startup finished in 1.308s (kernel) + 1.310s (initrd) + 7.557s (userspace) = 10.176s disable dbxtool.service Startup finished in 1.302s (kernel) + 1.291s (initrd) + 7.527s (userspace) = 10.120s disable import-state.service Startup finished in 1.308s (kernel) + 1.326s (initrd) + 7.410s (userspace) = 10.044s disable iscsi.service Startup finished in 1.316s (kernel) + 1.303s (initrd) + 7.177s (userspace) = 9.797s disable libvirtd.service Startup finished in 1.316s (kernel) + 1.266s (initrd) + 6.779s (userspace) = 9.361s disable lvm2-monitor.service Startup finished in 1.315s (kernel) + 1.323s (initrd) + 6.750s (userspace) = 9.389s disable mdmonitor.service Startup finished in 1.316s (kernel) + 1.350s (initrd) + 6.675s (userspace) = 9.342s disable ModemManager.service Startup finished in 1.270s (kernel) + 1.305s (initrd) + 7.052s (userspace) = 9.629s disable nfs-convert.service Startup finished in 1.312s (kernel) + 1.343s (initrd) + 6.958s (userspace) = 9.614s disable rngd.service Startup finished in 1.308s (kernel) + 1.277s (initrd) + 5.247s (userspace) = 7.833s disable switcheroo-control.service Startup finished in 1.308s (kernel) + 1.334s (initrd) + 5.223s (userspace) = 7.867s disable vboxservice.service Startup finished in 1.301s (kernel) + 1.302s (initrd) + 5.176s (userspace) = 7.780s disable crond.service Startup finished in 1.310s (kernel) + 1.278s (initrd) + 5.076s (userspace) = 7.665s
preset-all Startup finished in 1.316s (kernel) + 1.312s (initrd) + 7.869s (userspace) = 10.498s ##stopwatch 11.35 disable atd.service crond.service iscsi.service rngd.service vboxservice.service Startup finished in 1.305s (kernel) + 1.294s (initrd) + 5.505s (userspace) = 8.105s ##stopwatch 8.89
All of these times are based on 'systemd-analyze'. The stopwatch method is less precise but still demonstrates the difference is real.
It may not be a big enough deal to do anything about it this cycle, but could be something to look at for the next. Maybe more opportunities are available.
-- Chris Murphy
On Sat, Aug 29, 2020 at 09:27:33PM -0600, Chris Murphy wrote:
Hi,
These are based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso in a VM. The numbers are different on bare metal but correlate.
The only standout is rngd.service. That's a pretty big single hit, percentage wise. And I don't know if we even need it anymore. Among the rest, perhaps atd.service and crond.service could be disabled by default on new installations, in favor of systemd timers.
I think that with the recent-ish kernel changes to make /dev/urandom non-blocking, rngd should not be installed by default.
As for crond and atd, I think we can keep them installed by default, but inactive. I.e. make them socket activated or path activated, so that they are only started if people install actual crontabs or run at.
We would also need to convert any packaged cronfiles into systemd timers. But it seems that this is already mostly done. On my machine, /etc/cron.weekly/98-zfs-fuse-scrub is the only real crontab entry.
Those are not big programs, but each thing that is running on a machine has some small impact...
I see the appeal of keeping them functional by default: there are countless manual on the web, and even if people use them nowadays much less than in the past, it'd still be nice to make this "just work" for people who follow them.
In the past, I saw pcp as a fairly big offender. I'm not sure if it still installed by default.
Zbyszek
On Wed, Sep 2, 2020 at 1:09 pm, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
As for crond and atd, I think we can keep them installed by default, but inactive. I.e. make them socket activated or path activated, so that they are only started if people install actual crontabs or run at.
I don't think they're really needed because any packaged service that requires them could just add an appropriate Requires. And if you're trying to run a custom unpackaged service, it shouldn't be hard to install.
https://pagure.io/fedora-workstation/issue/183
We would also need to convert any packaged cronfiles into systemd timers. But it seems that this is already mostly done. On my machine, /etc/cron.weekly/98-zfs-fuse-scrub is the only real crontab entry.
I also noticed that yesterday:
https://bugzilla.redhat.com/show_bug.cgi?id=1874553
Michael
On Wed, 2 Sep 2020, Michael Catanzaro wrote:
On Wed, Sep 2, 2020 at 1:09 pm, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
As for crond and atd, I think we can keep them installed by default, but inactive. I.e. make them socket activated or path activated, so that they are only started if people install actual crontabs or run at.
I don't think they're really needed because any packaged service that requires them could just add an appropriate Requires.
Agreed, although perhaps there is some benefit to doing this anyway, for upgrading users who have atd and crond installed and running but are not using them.
On Sat, 2020-08-29 at 21:27 -0600, Chris Murphy wrote:
Hi,
These are based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso in a VM. The numbers are different on bare metal but correlate.
The only standout is rngd.service. That's a pretty big single hit, percentage wise. And I don't know if we even need it anymore. Among the rest, perhaps atd.service and crond.service could be disabled by default on new installations, in favor of systemd timers.
Well, what rngd does is highly system dependent, and in a VM it's gonna depend to a degree on exactly how the VM is configured (whether you attach some kind of virtual hwrng to the VM and if so how it's set up exactly). You'd want some data from real systems and probably different VM configs before deciding rngd is a big problem.
On Wed, Sep 2, 2020, 12:16 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Sat, 2020-08-29 at 21:27 -0600, Chris Murphy wrote:
Hi,
These are based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso in a VM. The numbers are different on bare metal but correlate.
The only standout is rngd.service. That's a pretty big single hit, percentage wise. And I don't know if we even need it anymore. Among the rest, perhaps atd.service and crond.service could be disabled by default on new installations, in favor of systemd timers.
Well, what rngd does is highly system dependent, and in a VM it's gonna depend to a degree on exactly how the VM is configured (whether you attach some kind of virtual hwrng to the VM and if so how it's set up exactly). You'd want some data from real systems and probably different VM configs before deciding rngd is a big problem.
rngd has come up before for removal
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
I have a laptop that was once negatively affected by rngd's removal, but it hasn't been that way in any of my f33 testing with it removed - I assume due to the somewhat recent kernel changes to making sufficient entropy available in early boot.
I've tested default virt-manager and GNOME Boxes environments; two different makes of laptop; and a different make of desktop. All are delayed by 2-4 seconds when enabled. And none are improved.
But it's valid to understand if this high cost has some sort of on-going value.
And I also haven't tested at all on other archs.
Anyway, Workstation WG has a proposal to remove it. https://pagure.io/fedora-workstation/issue/184
-- Chris Murphy
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Chris Murphy -
Michael Catanzaro -
Peter Oliver -
Zbigniew Jędrzejewski-Szmek