On Tue, 11 Mar 2014 12:20, Jason
Hi Yamaban, <snip>
Look into your /boot dir, add the size of your kernel and your initrd.
Look at the specs of your disk, continous transfer-rate, take about 60% of that (some UEFI implemtations are a little better and reach 80%).
Insufficient data to perform calculation. Based on what should I take 60 or 80% percent?
either your disc datasheet (Manfufac.Website->DiscModell->Tech.data) or by using hdparm -t [/dev/your-disc] e.g. /dev/sda, please see "man hdparm" beforehand. "continous transfer-rate" means transfers bejond internal disc-cache, e.g. more than 64MB. "hdparm -t" does that. This transfer-rate is measured with good drivers in a working OS. UEFI / BIOS use "barebones" essential generic dirvers to access the disc and thus reach at max 60% (most BIOS, early UEFI) to 80% (best BIOS, some recent UEFI) of that maxima.
Divide the sum of kernel and initrd by the reduced transferrate.
Now you have the pure time it takes to load the kernel and the initrd into memory.
If you take a older Laptop HDD (27 MB/s) and a newer SSD (150MB/s) the difference looks big, but the size of the kernel+initrd is not that big that the difference will make more than one (1) second of boot time.
This is simply not true.
I've had a 3.5" HDD with 30 MB/s and now a SSD with 120 MB/s. the time from end-of-grub to begin-kernel-init didn't shink to 25% (theoretical) but reached 30% (still good, IO saturation) At a kernel of 4.5 MB and a initrd of 10.5 MB that makes: 15 MB / 30MB/s = 0.5 sec 15 MB / 100MB/s = 0.15 sec "BIG" difference. This is the time it takes for the boot-loader (grub/grub2/lilo/gummiboot/syslinux/etc) to load the kernel and its initrd into memory. Then the boot-loader starts / executes the kernel.
After the kernel is loaded, the BIOS / UEFI will give control to the kernel, which initializes the HW with its drivers. Here comes the kernels own IO routines to play.
Now the kernel loads the rest of the OS with its own (optimized) routines.
And here most of the Disk I/O of the Boot / Restore process happens.
Restore after hibernate happens after the kernel initalises all the hardware, then the 'hibernate' image is loaded from the swap partition. In most cases the size of this image is about 1/4 to 1/2 of the size of the RAM. 4BG RAM => 1GB to 2GB to transfer from disc into memory Sample for 1GB: 1000MB / 30MB/s = 33.33 sec 1000MB / 100MB/s = 10 sec Now, this is really felt and experienced difference. For a 'normal' / full boot the summed size of all transfers is about the same, but more spread out and mixed in between the start-up of all the different services needed. Still, the most 'win' a SSD brings in full boot is the missing seek-times due to having no moving parts.
No.
BIOS/UEFI btl> secondary bootloader> Init> kernel > userspace
Please correct this in Your notes: BIOS/UEFI btl> secondary bootloader> (load kernel+initrd into mem) > start kernel > Init > deamons (userspace) > Ready-to-use
BIOS/UEFI ctl is relinquished moment it hands over to secondary btl. Exception is in some cases where thermal tables of the _hardware_ can be changed during run time by UEFI and few other bits, but nothing related to actual boot.
This differs from model to model. For some models the BIOS / UEFI data is discarded, and later reloaded by the BIOS / UEFI kernel-driver. For other the "secondary bootloader" has to hand trough the data, or the kernel could not start correctly (later reload fails, mostly older model, or 'mobiles') In the end what I'm trying to communicate is: The most speed-up a SSD vs a HDD gives, is after the kernel and the initrd it self is loaded. And this is proven. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org