On 12/04/17 14:59, Oliver Henshaw wrote:
On 12 April 2017 at 06:33, Terry Barnaby <terry@xxxxxxxxxxx> wrote:
With a 50s boot to login screen that gives:
Startup finished in 2.069s (kernel) + 3.395s (initrd) + 25.451s (userspace)
= 30.915s
12.391s systemd-journal-flush.service
8.049s lvm2-monitor.service
7.862s systemd-udev-settle.service
7.502s dev-sda5.device
6.231s packagekit.service
5.528s abrtd.service
5.030s accounts-daemon.service
4.937s boapns.service
4.245s NetworkManager.service
2.751s systemd-logind.service
...
This looks like the old bug with journal flushing drastically slowing
boot - https://bugzilla.redhat.com/show_bug.cgi?id=1006386 - which I
think was partly mitigated until the removal of readahead made it
worse again. The problem is (a) flushing the journal to disk (which
involves reading the old journal from disk) when there's a lot of
other i/o going on takes too long; (b) any process that tries to log
to the journal while this is going on will stall. That's why you see
multiple services taking seconds in the blame, even ones that should
be taking almost no time.
Before I got a SSD I used to workaround it by crudely reading in the
journal before flushing it:
$ cat /etc/systemd/system/systemd-journal-flush.service.d/preread-journal.conf
[Service]
ExecStartPre=/bin/dd if=/var/log/journal/%m/system.journal of=/dev/null
Hopefully this will improve things for you.
I don't think there are any issues with this particular laptop. All of my
other 10+ Fedora25 KDE/Plasma5 systems are basically the same, slow to get
to a logged in condition these days.
It just appears that Fedora Linux and particularly the KDE/Plasma software
is getting grossly inefficient and requires more and more random disk
accesses than before. I guess SSD's are covering this up to a fair extent,
but with rotating disk file systems and network files systems this doesn't
seem good to me.
All this stuff that shows up the the systemd-analyze blame is largely
independent of KDE/Plasma. Though I do expect that sddm could start up
a little faster, and obviously the long login time is Plasma's
responsibility. The login time might get better over time, but either
way a SSD is a magic bullet here.
Something I've found useful to understand boot times is
"systemd-analyze plot > blah.svg" to get a bootchart, which might give
you visual clues about bottlenecks. Particularly as you say there's a
50 second boot to login screen but systemd-analyze only reports 30
seconds - it wold be interesting to see what happens between when
sddm.service is activated and the end of the bootchart.
_______________________________________________
Yes, the systemd-analyze is not really showing anything of the
KDE/Plasma. This particular laptop takes about 30s to get to an non sddm
console login as borne out by the systemd-analyze. I guess only a new
readahead system will likely help this for spinning disks and network
drives, apart from your tweak above. I guess the parallel nature of
systemd is not helping here (random block reads all over the place).
But SDDM takes about 20s on its own (not in the systemd-analyze) ! And
sddm is a trivial/noddy program that does not do a lot at all, should
take < 100ms. This is followed by a KDE/Plasma startup time of 50s. So
overall the Linux boot is 30s and KDE/Plasma (sddm + user login) is 70s
which seems an awful lot to put an image on the background and display a
few icons ( :) ).
Although using an SSD is a workaround, I don't think the system,
shouldn't be as grossly inefficient as this. Imagine the speed on an SSD
system with an efficient desktop boot :)
Anyway, I am just asking, if anyone who understands the architecture of
KDE/Plasma5 thinks the performance of this aspect will likely improve or
get worse and why KDE/Plasma5 is so much worse than previous versions on
spinning disk systems.
Cheers
Terry
_______________________________________________
kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx
