yet another boot speedup patch for 14.2

SCerovec · 08-13-2016, 03:39 PM

Now i know each and every while this emerges:
Just how fast is Slackware and is it worth speeding up it's boot sequence.

I beg bare with me just for a brief moment:
I really don't alter the sequence not a tiny bit;

I merely just postpone few resource-hogs for the time we (hopefully) are on Desktop Environment and wait the browser start or calendar sync or whatever.
So I merely time-shift few (four) particular startup parts for not more than two minutes,and gain "to desktop time" in below a minute on this 10 year old laptop (DDR2 core duo).

So if anyone considers this useful, just run the patch file against rc.M like this:

Quote:

#patch rc.M.patch /etc/rc.d/rc.M

and reboot

if You find it not worthy, just replace the rc.M with the rc.M.orig that the patch utility left "behind".

the file [rc.M.patch]:

Code:

12a13,34
> #
> # the colors for output
> #
> # GPL v3 (2007-2016) cest73@gmail.com
> #
>         _end="\033[0m"
>   _dark_gray="\033[1;30m"
>         _red="\033[1;31m"
>       _green="\033[1;32m"
>      _yellow="\033[1;33m"
>        _blue="\033[1;34m"
>      _purple="\033[1;35m"
>        _cyan="\033[1;36m"
>       _white="\033[1;37m"
>       _black="\033[0;30m"
>    _dark_red="\033[0;31m"
>  _dark_green="\033[0;32m"
>      _orange="\033[0;33m"
>   _dark_blue="\033[0;34m"
>      _violet="\033[0;35m"
>   _dark_cyan="\033[0;36m"
>        _gray="\033[0;37m"
16a39,45
> echo -e "$_green delay loaders: $_end, we un-burden the startup by delay"
> # we approximate here the time to get the user logged in
> delay1=45
> delay2=$(($delay1 + 12))
> delay3=$(($delay2 + 11))
> delay4=$(($delay3 + 19))
> 
20c49,50
<   /sbin/ldconfig &
---
>   #reniced loaders: (25 sec delay)
>   ionice -c3 nice -n 19 sleep ${delay1}&& /sbin/ldconfig &
83c113,114
<   /usr/bin/fc-cache -f &
---
>   #reniced loaders: (even ome - 45 sec delay)
>   ionice -c3 nice -n 19 sleep ${delay2} && /usr/bin/fc-cache -f &
171c202,203
<       /usr/bin/gtk-update-icon-cache -t -f ${theme_dir} 1> /dev/null 2> /dev/null &
---
>       #reniced loaders (late ~95 sec delay):
>       ionice -c3 nice -n 19 sleep ${delay3} && /usr/bin/gtk-update-icon-cache -t -f ${theme_dir} 1> /dev/null 2> /dev/null &
185c217,218
<   /usr/bin/update-mime-database /usr/share/mime 1> /dev/null 2> /dev/null &
---
>   #reniced loaders (long awaited ~120 sec delay):
>   ionice -c3 nice -n 19 sleep ${delay4} && /usr/bin/update-mime-database /usr/share/mime 1> /dev/null 2> /dev/null &

- I believe the code is self expaining...
- i use this system since 14.0 and had no problem with it so far, the patch published is pulled from 14.2 running.
- regarding official inclusion - most of the postponed tasks can be run after setup, to prime what ever they do, so they won't be missed on first reboot and onward.

drmozes · 08-13-2016, 03:48 PM

Quote:

Originally Posted by SCerovec

> #reniced loaders: (25 sec delay)
> ionice -c3 nice -n 19 sleep ${delay1}&& /sbin/ldconfig &
[/CODE]

Aha. I think this might be an existing bug - backgrounding ldconfig.

It's probably unlikely for x86 but not on ARM where people set up file system's and the OS by editing the files and installing stuff directly into the file system, then booting into it. If they (me as I did many times) forget to run ldconfig -r. within the root fs, then your system won't boot at all, or break some way along the path.

Also even without an /etc/ld.so.cache existing, ldconfig completes within 0.450ms on ARM. It's not worth forking it into the background - it's probably slower!

The others also fall into this category.

Can you remove the backgrounding and nice thing and re-test to check?

SCerovec · 08-13-2016, 05:23 PM

Quote:

Originally Posted by drmozes

Aha. I think this might be an existing bug - backgrounding ldconfig.

It's probably unlikely for x86 but not on ARM where people set up file system's and the OS by editing the files and installing stuff directly into the file system, then booting into it. If they (me as I did many times) forget to run ldconfig -r. within the root fs, then your system won't boot at all, or break some way along the path.

Also even without an /etc/ld.so.cache existing, ldconfig completes within 0.450ms on ARM. It's not worth forking it into the background - it's probably slower!

The others also fall into this category.

Can you remove the backgrounding and nice thing and re-test to check?

Kind thanks for the feedback.

As You can imagine, I did profile the whole rc.M until i found the points that delay the startup the most.
It was on a core duo class laptop with an SATA2 class HDD.

I do imagine Your ARM is an embedded (no HDD) computer with selected only *.so deployment?

Or You tested it on official complete Slackware for ARM and an SD-card/Flash storage?

I can imagine all the boot-up delay is from the head-seek-wait?

But to make it worse by delaying it? Maybe only if the SSD/flash/SD-card gets confused and likes co-locating writes in time?

Then i guess this optimization would not apply for solid state root filesystem?

I do have an RasPi handy to check this when time permits, not that a "headless" server would benefit of it much...

atelszewski · 08-13-2016, 06:12 PM

Hi,

If you want to have real speed-up, you have to start with hardware. This basically means buying yourself SSD.
In my case, the boot time has lowered from ~60 seconds to just below 20 seconds.

Also, in /etc/rc.d/rc.S, you can in most cases safely comment out "sleep 3" just after "Mounting non-root local filesystems:".

Then you have to be careful with daemons start-up time. For example, libvirtd seems to take quite some seconds to load.

All that being said, most of the time I'm using hibernation. My system resumes in just about 20 seconds, even if I have 2 virtual machines (Windows 7, Slackware 14.2), running at the time of hibernation.

--
Best regards,
Andrzej Telszewski

drmozes · 08-14-2016, 02:33 AM

Quote:

Originally Posted by SCerovec

I do imagine Your ARM is an embedded (no HDD) computer with selected only *.so deployment?

Or You tested it on official complete Slackware for ARM and an SD-card/Flash storage?

No, it's the build machines which have the full OS on an SDD and the tty opens as usual - one of them has an HDMI monitor and the others open a tty through the serial port.

The point I'm making is that those commands take so little time to run that there's no point in backgrounding them, in my opinion; but I haven't tested that theory I only timed ldconfig
I suspect that making it foreground makes no _perceivable_ difference though.

SCerovec · 08-14-2016, 08:18 AM

@drmozes
1. as noted above, SSD are game changers, agreed. Even MMC/SDcards.
2. I have yet to find a 1TB storage device in SSD that i can afford,...
until then my desktop stays on turning platters, and those four get "backgrounded"
on my place at least

I just wanted to share if anyone finds it fit...

slackb0t · 08-14-2016, 09:01 AM

I found some of those tweaks helpful on my older machines. When your boot time is over 1 min saving 5 or 10 seconds can seem significant.

My current machine boots in approx 7 seconds so I probably won't bother this time around.

drmozes · 08-14-2016, 09:18 AM

Quote:

Originally Posted by SCerovec

@drmozes
1. as noted above, SSD are game changers, agreed. Even MMC/SDcards.
2. I have yet to find a 1TB storage device in SSD that i can afford,...
until then my desktop stays on turning platters, and those four get "backgrounded"
on my place at least

I just wanted to share if anyone finds it fit...

I get what you're saying, but on an x86_64 with a normal spinning HDD (not SDD) 2.5" disc:

Code:

root@kitt:~# smartctl -a /dev/sda| grep -i 'Model'
Model Family:     Seagate Momentus 7200.4
Device Model:     ST9160412AS
root@kitt:~# time ldconfig

real    0m0.174s
user    0m0.134s
sys     0m0.039s
root@kitt:~# rm -f /etc/ld.so.cache
root@kitt:~# time ldconfig

real    0m0.148s
user    0m0.130s
sys     0m0.018s
root@kitt:~# time ldconfig

real    0m0.148s
user    0m0.129s
sys     0m0.019s

atelszewski · 08-14-2016, 09:20 AM

Hi,

Quote:

Originally Posted by slackb0t

My current machine boots in approx 7 seconds so I probably won't bother this time around.

Wow. Is it only thanks to the hardware?

--
Best regards,
Andrzej Telszewski

drmozes · 08-14-2016, 09:27 AM

Quote:

Originally Posted by drmozes

I get what you're saying, but on an x86_64 with a normal spinning HDD (not SDD) 2.5" disc:

Code:

root@kitt:~# smartctl -a /dev/sda| grep -i 'Model'
Model Family:     Seagate Momentus 7200.4
Device Model:     ST9160412AS
root@kitt:~# time ldconfig

real    0m0.174s
user    0m0.134s
sys     0m0.039s
root@kitt:~# rm -f /etc/ld.so.cache
root@kitt:~# time ldconfig

real    0m0.148s
user    0m0.130s
sys     0m0.018s
root@kitt:~# time ldconfig

real    0m0.148s
user    0m0.129s
sys     0m0.019s

Compare this with running it through ionice :

Code:

root@kitt:~# time ionice -c3 nice -n 19 ldconfig

real    0m0.160s
user    0m0.146s
sys     0m0.014s

Run it a few times to see the results, but it's always slower to run through ionice. What you propose makes sense if the tools took a long time to run -- which they would have in the past, but don't any more on modern hardware.

SCerovec · 08-14-2016, 03:42 PM

funny enough, my system does run it similarly fast?

Code:

bash-4.3# smartctl -a /dev/sda| grep -i 'Model'
Model Family:     Seagate Samsung SpinPoint M8 (AF)
Device Model:     ST320LM001 HN-M320MBB
bash-4.3# time ldconfig

real	0m0.220s
user	0m0.155s
sys	0m0.037s
bash-4.3# rm /etc/ld.so.cache
bash-4.3# time ldconfig

real	0m0.213s
user	0m0.166s
sys	0m0.026s
bash-4.3# time fc-cache

real	0m0.052s
user	0m0.007s
sys	0m0.003s
bash-4.3# time gtk-update-icon-cache 

real	0m0.050s
user	0m0.000s
sys	0m0.003s
bash-4.3# time update-mime-database /usr/share/mime

real	0m1.656s
user	0m0.878s
sys	0m0.203s
bash-4.3#

however, including the patch to rc.M saves no less than 12 seconds to login

how about that?

give it a try:
add a uptime command to rc.local and boot with and without my patch? i use it since 13.37 'til now.

postponing:
ldconfig
fc-cache
update-icon-cache
update-mime-data-base
ought to make the boot sooner to login (init 4)
having autologin (my personal case)
and few other tweaks not included for it to be a clean patch
one saves at least about 7 or more (up to 17) seconds...
amongst them is the 5->2 sec HDD mount delay and any other unconditional sleep issued all a long (in inet1.conf i limit the dhcpd wait to 2 sec too)

now maybe ldconfig and fc-cache aren't spectacular savings, but they seemed to slow the rc.M and once postponed it aparently exited sooner?

maybe time Your non-patched vs patched rc.M ?
of course same applies to rotating discs, not SSD

with their large ram caches.

slackb0t · 08-14-2016, 03:51 PM

Quote:

Originally Posted by atelszewski

Hi,

Wow. Is it only thanks to the hardware?

--
Best regards,
Andrzej Telszewski

Yes, it is all hardware... no software tweaks. SSD boot times are ridiculously fast.

pchristy · 08-15-2016, 03:06 AM

Quote:

Originally Posted by SCerovec

@drmozes
2. I have yet to find a 1TB storage device in SSD that i can afford,...

Me too, so what I did was get a small and affordable SSD (120GB) and use it for my system, whilst home, data and archive partitions go on a normal HDD. Result? Very fast boot, but plenty of storage space!

sda1 10MB efi boot partition
sda2 60GB root partition (15GB used with Slack 14.2)
sda3 4GB swap
47 GB unallocated - for future second OS installation?

sdb1 /home
sdb2 /data
sdb3 /archive

The system boots like greased lightning!

However, I also have an old, but very useful Acer Aspire One mini-laptop. It has a 1TB spinning rust disk, and takes forever to boot! I will probably give your speed up method a try on that.

(In case anyone is wondering why I'm still using an elderly laptop like that, it handles hi-def video with the linux kernel drivers, has an hdmi output, and is very compact. And I don't like touch screens! Its almost impossible to find anything like that nowadays!)

--
Pete

drmozes · 08-15-2016, 06:01 AM

Quote:

Originally Posted by pchristy

The system boots like greased lightning!

OK I will have a play around with this before I blow away the OS and reinstall. I'm curious as to why it's faster.

kjhambrick · 08-15-2016, 06:13 AM

All --

Yes, Slackware boots in a jiffy-or-two from an SSD ( mine gives me a runlevel 3 login in about 10-sec, including starting up Moria, Postgresql and VMWare Workstation ).

One Q though about installing root on the SSD ...

What do Y'All do about /tmp/ and /var/ ?

I am looking for a good solution for 'hybridizing' some Linux Appliances ( SSD + HDD ) and it seems like I don't want /var/ and maybe not even /tmp/ on the root SSD ...

Thanks in advance.

-- kjh