Re: [boot-time]

Hello Tim, all,

Am 08.01.25 um 19:33 schrieb Bird, Tim:
>> -----Original Message-----
>> From: Shankari <[email protected]>
>> Hi
>>
>> I wanted to provide an update on my recent contributions to the boot-time reduction project. I have recently started contributing and
>> am working with the beagleplay. I have been analyzing the boot time of the init process. Below is the output from the system log:
>>
>> debian@BeaglePlay:~$ dmesg | grep "init process"
>> [    1.480490] Run /init as init process
>>
>> Moving forward, I plan to explore ways to modify the command line and further investigate the data used for SIG analysis. This will
>> help me gain a deeper understanding of the boot process and its performance characteristics.
>>
>> Please let me know if you have any suggestions or areas where I could focus my efforts.
> Hi Shankari,
>
> It sounds like you are off to a good start.  I have something that needs to be done, that I think
> you can help with, and that matches where I believe you are in your status with being able
> to evaluate the kernel.
>
> In general, there's a lot of information on the elinux wiki which is stale, which needs to be
> updated or archived, or maybe even just removed.
>
> This section of the Boot Time page has a lot of material in this category:
> https://elinux.org/Boot_Time#kernel_speedups
>
> Can you validate the information on these 2 pages:
>   * https://elinux.org/Disable_Console
>   * https://elinux.org/Preset_LPJ
>
> This would consist of reading through the material, and testing the
> described techniques on your machine.  This will involve booting the
> machine 2 ways, with a particular kernel command line option and without
> it, and then reporting back the final boot time for both.  You can use
> the timestamp for the "init process" string as your final boot time, for the
> purposes of this exercise.
>
> Helping me to update the elinux wiki material on boot time would be
> an immense help, and is one of my main goals for the boot time SIG in 2025.
>
> Don't hesitate to ask questions if you have any.
>
> BTW - you can just report your findings to me and linux-embedded list, but
> alternatively (and even better) would be if you could also update the wiki
> pages themselves with your information based on recent kernels and hardware.
> To do this, you will need an elinux wiki account, which you can make online on
> elinux wiki.org by going to this page: https://elinux.org/Special:CreateAccount
>
> Anyone else reading this who wants to also participate in this project to
> update the elinux wiki boot time information, please contact me.

I'm just going through the "userspace application speed-up" parts in the 
wiki.


To the udev stuff ("Avoid udev, it takes ..." and "If you still like udev"):

* both hints seem to be a bit old fashioned to me taking the kernels 
devtmpfs into account

* In my experience, device nodes are created by the kernel today, I 
never needed to use any kind of mknod call anymore

* udevs job today is mostly about

     - setup of access rights and user and group ids of device nodes

     - creating symlinks (e.g. for partitions named w/ their UUIDs, ...)

     - loading kernel modules

     - annotating metadata to uevents for interested userspace applications

* In any way, udev is still very expensive when used the conventional way

     - Once udev is started, a trigger is send (by 
systemd-udev-trigger.service or udevadm trigger, for those who don't 
like systemd ;)) through the whole device tree to let all devices sent 
uevents again so that udev can work on each device. This causes massive 
CPU load for e few seconds you don't want to spend so early in the morning.

* There are options like selective triggering or moving the trigger back 
in time and do the setup manuelly ...

So I think it is worth talking a bit about udev and options to deal with 
it but adapting thinks a bit to todays world. I'm currently registering 
for the wiki, maybe I can setup an initial page at some time ...

Btw: If I'm wrong with my experiene about devtmpf and mknode, please 
correct me. And feel free to add other ideas to cope w/ udev in context 
of startup time critical systems ...

Regards,

Marko