Optimizing the boot process of FreeBSD came up as a Google Summer of Code Project in 2025. This project has been supervised by Colin Percival and Toomas Soome. The optimization was first approached by gaining the fundamental understanding of the boot process of the FreeBSD operating system by going through the following documentation:
In the first stage, FreeBSD was installed on a Virtual Box virtual machine. Subsequently the FreeBSD source code was cloned from https://git.freebsd.org/src.git into /usr/src directory of the FreeBSD System. Next, a separate kernel configuration named BOOT_PROF was created by inheriting the GENERIC profile, by enabling the option TSLOG in /usr/src/sys/amd64/conf/BOOT_PROF.
include GENERIC
# Boot profiling
options TSLOG
Afterwards, the kernel was built and installed using make buildkernel KERNCONF=BOOT_PROF and make installkernel KERNCONF=BOOT_PROF. Alternatively the command make kernel KERNCONF=BOOT_PROF can be used to both build and install at once. The boot sequence profiling tool available at freebsd-boot-profiling was utilized to generate flamecharts to identify the delays and the bottlenecks in the system boot process.
sh mkflame.sh > [filename].svg
Execution of the above produced the first flame chart of the FreeBSD boot sequence. For data transfer, images were shared with remote systems either by piping output through curl into dpaste.com or by installing and enabling a desktop environment such as "KDE" on FreeBSD. Otherwise, a flash drive formatted to "zfs" or "ufs" has to be used to transfer the files.
The initial flame chart revealed that BIOS time was reported as excessively long (5055574 ms ~ 1.4 hrs). This behavior was attributed to the virtualized environment, where CPU time is obtained from the host operating system, and it was not reset at the moment the virtual machine is powered on.
Initial flamechart generated in VM indicated nearly 1.4hrs of startup time (Please scroll to the right)
As main findings, the following aspects were identified in the kernel space as potential bottlenecks in the boot process:
To achieve more accurate and reliable results, boot profiling was repeated on physical hardware with the following specifications:
The physical hardware environment provided a more realistic representation of the boot process, eliminating the anomalies observed in the virtual machine setup. Subsequent research revealed that more significant opportunities existed in device attachment routines and ZFS initialization in kernel space. The clock calibration clockcalib time which took additional time in the virtual machine did not appeared in the physical hardware. The time spent in the bootloader was happend due to the 10 seconds delay to choose boot options. When the autoboot_delay was reduced to "0", that time flame has disappeared.
Initial flamechart generated in the physical hardware (42s boot time with 8.2s kernel initialization time)
The flame chart produced under this environment exposed the following critical delays in the kernel:
DEVICE_ATTACH atkbd and DEVICE_ATTACH psm (PS2 keyboard and PS2 mouse initialization)SYSINIT zfsctrlmodulevfs_mountrootBy adding TS logs to the FreeBSD source tree, deeper insights were gained into the boot process and identified specific areas for optimization, as the following image shows.
Generated flamechart after adding more TS logs into the FreeBSD source tree in physical hardware
The identified bottlenecks were addressed through targeted optimizations as mentioned below.
The checksum initialization in zfs_kmod_init was identified as a major bottleneck. The initial benchmarking was being performed with a 16 MB data buffers, which caused unnecessary overhead. This was reduced to 256 KB, resulting in a substantial performance improvement. The issue was discussed with the OpenZFS developer team and resolved upstream
(OpenZFS issue #17560).
Generated flamechart after optimizing the benchmarking (38s boot time with 6.8s kernel initialization time)
Significant delays were observed in the atkbd_attach and psmprobe routines, specifically within the empty_both_buffers, reset_kbd and reset_aux_dev functions.
These routines contained wait loops originally intended to accommodate older, slower hardware such as i8042 keyboard controller 8042 keyboard controller. Modern hardware devices no longer require such long delays. By reducing these wait times, the initialization of keyboard and mouse devices was significantly improved. In this improvement a tunable was introduced hw.atkbd.short_delay to set to "zero" in /boot/loader.conf to run in FreeBSD with longer delays if needed with old PS2 hardware. Pull request
Generated flamechart after optimizing the delays in PS2 keyboard and mouse initialization (34.7s boot time with 3.5s kernel initialization time)
vfs_mountroot)
Investigation into the waits occurring in vfs_mountroot revealed that no feasible optimizations were possible within this subsystem at the moment. However, enabling the tunable hw.usb.no_boot_wait=1 skips waiting for USB devices to fully initialize during boot. This reduces the kernel’s startup time, as the system no longer pauses for USB device enumeration.
Generated flamechart after setting the tunable hw.usb.no_boot_wait=1 in the /boot/loader.conf (33s boot time with 1.9s kernel initialization time)
Kernel-level profiling and analysis revealed that device attachment and ZFS initialization were the principal sources of delay during boot.
Targeted optimizations, most notably reducing unnecessary waits in input device initialization and optimizing checksum benchmarking in ZFS, yielded measurable improvements, cutting kernel initialization time from about 8.2 seconds to 3.5 seconds.
While some delays, such as those in vfs_mountroot, remain unavoidable, the applied changes represent meaningful progress toward a faster and more efficient FreeBSD boot process.
With these kernel bottlenecks addressed, attention can now shift toward optimizing the userland phase in future work.
For more details, see the FreeBSD wiki.