10:27 p.m.
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
8:09 a.m.
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
8:27 a.m.
On Wed, Sep 2, 2020 at 1:09 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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
5:23 a.m.
On Wed, 2 Sep 2020, Michael Catanzaro wrote:
On Wed, Sep 2, 2020 at 1:09 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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.
--
Peter Oliver
1:16 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:10 p.m.
On Wed, Sep 2, 2020, 12:16 PM Adam Williamson <adamwill(a)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.o...
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
1329
days inactive
1333
days old
desktop@lists.fedoraproject.org
5 comments
5 participants
participants (5)
-
Adam Williamson -
Chris Murphy -
Michael Catanzaro -
Peter Oliver -
Zbigniew Jędrzejewski-Szmek