> -----Original Message----- > From: Francesco Valla <francesco@xxxxxxxx> > Dear fellow boot time optimizers, > > following the first boot time SIG meeting, which I lurked with much pleasure > (but didn't participate to, as I was a bit in awe among such authorities), I'd > like to introduce myself with code rather than a presentation or resume. > > Here is a python script which can analyze a dmesg output with initcall_debug > option enabled and extract some useful information. It can for example be used > to analyze the output of the grab-boot-data.sh tool that Tim presented on this > list [1] just a few days ago. > > Usage is very simple, as the output of dmesg can be piped directly to it: > > dmesg | analyze-initcall-debug.py > > If no option is specified, it outputs a brief summary, like the following one > (obtained on my Beagleplay): > > 1758 drivers has been initialized, of which 1758 before userspace > 119 probes happened outside of the init of their driver > 0 deferred probes pending > --- > Top 10 init/probes durations: > * 30200000.dss -> 523002us > * deferred_probe_initcall -> 487483us > * fd00000.gpu -> 162859us > * 8000f00.mdio -> 142521us > * 44043000.system-controller -> 71390us > * 2-004c -> 71178us > * 40900000.crypto -> 59350us > * 8000000.ethernet -> 58419us > * 44043000.system-controller:clock-controller -> 56599us > * jent_mod_init -> 52140us This is odd. On my beagleplay board, jent_mod_init only took 32326us. (see https://birdcloud.org/boot-time-files/boot-data-timslab-bp1-241203-134136.txt) I'm assuming that we have similar hardware, but possibly different configs, kernel cmdlines or kernel versions. I'll take a look at this and see if I can figure out what the difference is between our systems, that causes the difference in the duration for this function. This initcall (jent_mod_init) is on my list of initcalls to research to see if they can be improved or deferred. I haven't seen any degradation in system behavior by deferring this initcall on my system, but that could be from lack of my system doing some related operation that needs the RNG data, or my own ignorance of the effects of this call. Can someone comment on what items or operations might depend on jent_mod_init in early boot? In particular, would we expect any cryptographic problems if the initcall was deferred to a few seconds after booting? It can be configured as a module, which makes me think that maybe loading it sometime in very late boot (or even later) is OK. jent_mod_init is defined in crypto/jitterentropy-kcapi.c, and controlled by CONFIG_CRYPTO_JITTERENTROPY (See crypto/Kconfig) It appears to do some random number generator seeding by measuring the jitter of a compressiong operation in the kernel. I assume some of the cryptography configs affect the duration of the operations. The initcall duration results on my beagleplay seem to be relatively consistent (in the 32ms range consistently), and from bobs_lab, on machine sam1, the duration range is also consistent (at between 4800 and 5200 usecs). I'd be interested to see if the range is consistent between runs on other machines Francesco - Can you submit another boot-data file (or 2 or 3) for francsecoslab-beagleplay, to provide some data on this? Also, can anyone else who sees this initcall in their boot sequence run grab-boot-data.sh (from https://birdcloud.org/boot-time/Boot-time_Tools) and submit the data for one or more of their machines? Stephan Mueller - what are you seeing for the cost of this operation on your machines? This is one of the first initcalls I'm going to dive into to see if it can be improved or deferred. Maybe some of the RNG seeding can be held over from a previous boot, in order to eliminate the overhead on the early portion of a current boot. Any feedback on that idea? Thanks. -- Tim
