Mailinglist Archive: opensuse-factory (439 mails)

< Previous Next >
Re: [opensuse-factory] Re: Re: Re: Adding SSDs?
  • From: Jason <relentropy@xxxxxxxxx>
  • Date: Tue, 11 Mar 2014 20:59:36 +0800
  • Message-id: <34866768.Ymy6zj9csp@host.laptop>
On Tuesday, March 11, 2014 13:27:25 Yamaban wrote:
On Tue, 11 Mar 2014 12:20, Jason <relentropy@...> wrote:
Hi Yamaban,


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->
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.

the only thing I see here affecting the boot is what driver is in use, IDE,
AHCI etc, but that would affect the whole of system.

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.

Ok, i think I see where is the problem in this discussion.

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.

I have misunderstood.

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.


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

Ok. I knew that but somehow misunderstood at some point.

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.

Agreed, I took it as actual full system boot somehow (up until userspace), not
that you're talking about kernel unpacking/transfer to RAM.

That said, it is really negligible what you pointed out. I'm using SSDs since
5yrs ago and couldn't go back to HDD at this point. The actuall boot got from
45 sec to 15 sec to usable desktop, depending on the machine. Therefore my
inital comment. I'm sorry for the confusion.

To extend, I might have approached this topic with you with prejudice that was
based on 20% non-partitioned space and daily chron job for trimming:) So I'm
sorry for that too.

- Yamaban.

Kind regards,
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >