Mailinglist Archive: opensuse-factory (439 mails)

< Previous Next >
[opensuse-factory] Re: Re: Re: Adding SSDs?
On Tue, 11 Mar 2014 12:20, Jason <relentropy@...> wrote:
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups