Re: [boot-time]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Tim, all,

Am 08.01.25 um 19:33 schrieb Bird, Tim:
-----Original Message-----
From: Shankari <beingcap11@xxxxxxxxx>
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






[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux