Re: [boot-time] jent_mod_init on beagleplay (was RE: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output

[Stephan Mueller <smueller@chronox.de>]

Am Dienstag, 3. Dezember 2024, 22:24:28 Mitteleuropäische Normalzeit schrieb 
Bird, Tim:

Hi Tim,

> > -----Original Message-----
> > From: Francesco Valla <francesco@valla.it>
> > 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.t
> xt)
 
> 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?

I have never done the measurements on my system, but with patch 
95a798d20060d2b648dd604321e347c85edfd783 the so-called oversampling rate was 
changed which reduced the performance of the Jitter RNG (read: it takes a bit 
more to gather all data).

 
> 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
> 


Ciao
Stephan