console-setup requires 800ms during a boot. The complete boot finishes in 4.1 seconds. This really should not be a shell script in the long term, but short term at least removing "fast" from the manual page would be a good idea... Here's a boot graph: https://people.debian.org/~jak/boot.svg
Julian Andres Klode, le Wed 01 Oct 2014 23:31:18 +0200, a écrit : That's odd, it shouldn't be taking so long, thanks to the caching in /etc/console-setup/cached.kmap.gz. You should probably check what is happening there. Samuel
One possible explanation is what Samuel Thibault proposed (for some reason setupcon doesn't use cached keymap). The following is (may be) another explanation. I don't know how exactly recent Debian systems boot so the following is only a guess. Considering that keyboard-setup.service uses only 190 ms compared to 823 ms for console-setup.service, I suppose that these 823 ms are caused by forked printf commands (by setupcon) waiting for the virtual consoles to become active. So during most of these 823ms the scripts were waiting and didn't consume cpu resources. If my hypothesis is true, the proper fix is to improve the description console-setup.service in order to run it only after the virtual consoles become active. This, however, is not something I can do (with my current knowledge). Anton Zinoviev
I am experiencing the same problem. I edited setupcon to add "set -x" at the beginning to help tracing where the slowness is. It doesn't look like printf is at fault. I also tried changing the amount of ACTIVE_CONSOLES in /etc/default/console-setup but it did not make much of a difference (I tried setting it to just tty1 and to the empty string). Logs, plots and systemd-blame at https://people.debian.org/~fsateler/console-setup/ Saludos
Dear Maintainer, inspired by the recent talk about systemd utilities I analyzed my boot process on my lower-level laptop (CPU is ok but the harddisk is plain old mechanic thing). And it's even worse than in jak's original report, it spends 5s there and the HDD seems to be pretty busy. Just have a look at it: https://www.unix-ag.uni-kl.de/~bloch/.wearetheborg/ $ wc -l log 23053 log $ grep ioctl log | wc -l 14035 OVER 9000 ioctls! Are you kidding me? $ grep 'open\|read\|stat' log | wc -l 3881 OVER 3000 filesystem related syscalls. That all is needed to just configure the console? Seriously? Please find a way to cut down this activity, there must be a way to do that. Regards, Eduard.
Dear Maintainer, inspired by the recent talk about systemd utilities I analyzed my boot process on my lower-level laptop (CPU is ok but the harddisk is plain old mechanic thing). And it's even worse than in jak's original report, it spends 5s there and the HDD seems to be pretty busy. Just have a look at it: https://www.unix-ag.uni-kl.de/~bloch/.wearetheborg/ $ wc -l log 23053 log $ grep ioctl log | wc -l 14035 OVER 9000 ioctls! Are you kidding me? $ grep 'open\|read\|stat' log | wc -l 3881 OVER 3000 filesystem related syscalls. That all is needed to just configure the console? Seriously? Please find a way to cut down this activity, there must be a way to do that. Regards, Eduard.
Hi Eduard, Eduard Bloch <bloch@unix-ag.uni-kl.de> (2015-08-22): Patches welcome. KiBi.
Console-setup is definitely not THAT slow. Unless your directory /etc/console-setup/ doesn't contain a cached keymap in which case ckbcomp has to be invoked. And yes - in this case it does use about 14000 ioctls. In my opinion, such results imply that the testing environment used for these results has not been configured properly. Things are not as bad as you think they are. :) Or maybe no pathes are needed... The general plan for console-setup must be to move the entire console configuration in the initrd. Console-setup already provides good and easy to use support for the initrd builders. Dracut already includes a script provided by console-setup (BTW, it is fast and simple...). It is only because of my lasiness that I haven't submitted wishlist bug reports for the other initrd-builders. If the console is configured, then the main scripts of console-setup don't have to reconfigure the console again. Right now they do reconfigure it but it is in my TODO list to fix this. Anton Zinoviev
Hallo, * Anton Zinoviev [Mon, Aug 24 2015, 01:24:15PM]: It is. Kind of. I checked again... about 20% of the time is spent in two calls of pidof which IMHO on Linux can be easily replaced with ONE simple readlink /proc/*/exe | grep bin/.?splashy? And about 70% is spent by loadkeys executing the mentioned storm of ioctls. https://www.unix-ag.uni-kl.de/~bloch/.wearetheborg/strace-log-setupcon.xz AFAICS no call of ckbcomp there. Regards, Eduard.
Hello, Eduard Bloch, le Tue 25 Aug 2015 20:24:22 +0200, a écrit : We could try to optimize that now by not loading the whole table, but just the parts for which a modifier key has been defined. That's not very clean since it'll leave unreachable parts of any previous load, but in the usual case that'll not be a problem. Samuel
Just so that people reading the log don't take it too exagerated: Eduard Bloch, le Tue 25 Aug 2015 20:24:22 +0200, a écrit : We're here talking about ~15ms each. And about 70ms. Samuel
Samuel Thibault, le Tue 25 Aug 2015 20:53:36 +0200, a écrit : I forgot to add that we could implement in Linux a KDSKBENTS which sets an array of entries, instead of just one, and then make loadkeys use it. It's a bug in the kbd package then. Samuel