you are saving will end up a 2 second saving.
That is the result of calculations, not empiric results. It takes indeed less time to load. The question ist: why?
Because the kernel does not spend time searching for devices which aren't included.
What is the ethernet controller hardware on your computer? re(4) is the device driver for a common ethernet adaptor, and miibus(4) is the device driver for the framework for talking to the media interface (the thing that controls whether the wire is 10bt or 100bt and such). If your hardware needs those drivers, and you don't have them, then at some point during the boot process you will lose ethernet access, and that's the end of booting.I have an almost minimal Kernel, 9796624 bytes, that works if I have in kernel config file: ...
and does not work if I do not have them, ...
Keep in mind that almost everything is actually a module. The kernel configuration basically defines which modules are statically linked into the kernel file.The delivered MINIMAL configuration file is interesting, because it exclude what can be load with kldload,
Read 31.8. Diskless Operation with PXE and diskless(8) to get a better idea of the various boot stages and steps with PXE booting., but unfortunately loader.conf seems not to be processed by PXE booting, or at least not at the appropriate time for booting with PXE.
There's no linear relationship between the kernel's size and the time it takes to load and initialize. There could be a very small module that takes a lot of time to initialize or the other way around. Loading the kernel is only part of the boot time, there's also some time required to probe and enable the various kernel modules.if I reduce the kernel to 1/3, then it will take 1/3 of the time?
[...] diskless(8) to get a better idea of the various boot stages and steps with PXE booting.
man pxeboot
:The pxeboot bootloader retrieves the kernel, modules, and other files either via NFS over UDP or by TFTP, selectable through compile-time options. [...] Note that pxeboot expects to fetch /boot/loader.rc from the specified server before loading any other files. [...] This may be changed by setting the nfs.read_size variable in /boot/loader.conf [...]
If you reduce the kernel to 1/3 the size, then just loading the kernel into memory from the file system (could be a remote file system in the case of a network boot) will take roughly 1/3 of the time. Which is the same as saying that reading a file that is 1/3 the size will take roughly 1/3 the time, because that's really what loading the kernel is: Open a file on a file system, perform a series of reads, and deposit the result in memory. This is slightly optimistic, since there is a constant overhead for finding and opening the file (about 100ms +- a factor of 10 either way), compared to a few seconds for the actual reading (assuming a 10 MByte/s speed), so it is not quite as good. This also assumes that the kernel is read completely and linearly, which I think is the case for the boot loader.BTW: if I reduce the kernel to 1/3, then it will take 1/3 of the time? This is another way of making the calculations that give a different result.