arch linux 启动优化(非wiki ,转)

回复
头像
john.wu
帖子: 1006
注册时间: 2007-10-18 17:40
送出感谢: 0
接收感谢: 0

arch linux 启动优化(非wiki ,转)

#1

帖子 john.wu » 2009-03-20 15:27

代码: 全选

 
Speedup Arch Boot Process

Jun 27th 2008

My Arch Linux box boots in  7 seconds. Schweeet… And that’s not a fresh Arch with only base apps installed, it’s a full-fledged Arch with XFCE and bunch of apps that I need (no redundancy, thanks). The only OS came close is Mac OS 10.4, which boots in 19 seconds. Windows XP boots in 27 seconds (SP2) and 30 seconds (SP3), both nlited, XUbuntu in 35 seconds, Vista (vlited) in 44 seconds, and openSUSE (already stripped down) in 50 seconds. All in the same machine (wait… 10.4? Go figure… hehe…). In this guide I will explain some of the tweaks I did related to the boot process speedup.

Disclaimer. This guide is written for people who like to tinker with their system, like to get their feet wet, and don’t cry when something bad happens. We will be working entirely on CLI so if you’re not comfortable with it, go get some coffee and watch movies instead. This guide contains tips and tricks from various places, notably the Arch Wiki and Forum, with some of them are the result of my own tweaking. These tweaks are applied on my system and it never had any craches or freezes or any other problems. It just works. Your mileage may vary. One strict rule of engagement: Always make a backup of everything you edit!
Use a faster filesystem

Various filesystems exist and what you’ll be using is entirely up to you. Every FS has goods and bads, but for this guide we’ll be using the fastest FS while maintaining high reliability and low CPU usage. My choice is JFS. It’s reasonably fast, if not the fastest at some points, it’s journaled, stable, reliable, and has very low CPU utilizations. Other options are ReiserFS (quite stable, faster), and Reiser4 (unstable, very fast). Changing filesystem type may require you to first erase the partition. If this isn’t viable, you can use whatever you already have right now. Or, do the tar routine. Or, use clonezilla. Whatever.
Trim your initrd

Go edit /etc/mkinitcpio.conf and trim it to your needs. Make it as compact as possible. This config will be used to generate an initrd, which will be loaded by the boot loader, sets your hardware (loading modules, etc) and mounting the filesystem. After that, it gives the control to the kernel. Delete hooks that you don’t plan on using, or don’t need to be loaded at this stage of booting process. Hardware configs will be done later after the kernel loads instead. In my case, my mkinitcpio.conf looks like this:

MODULES=""
BINARIES=""
FILES=""
HOOKS="autodetect base udev sata filesystems"

That will generate a very small initrd which is enough to mount the root filesystem and loads the kernel.
Trim your rc.conf

Two of the main delay when booting is loading daemons and modules. The other would be loading udev, which we will see later on. If you have more fancy hardwares, the kernel will load more modules to activate them. The wisest step would be disable the ones you don’t need via BIOS. The second wisest step would be to blacklist the modules. In short, just load modules and daemons you need. As for the daemons, replace some of them with more lightweight ones, FAM with Gamin, for example. My /etc/rc.conf looks like this (some lines omitted):

...
MOD_AUTOLOAD="yes"
MODULES=(powernow-k8 fglrx)
DAEMONS=(preload hal @cpufreq @network)
...

Trim your rc.sysinit

The file /etc/rc.sysinit is very important, it configures core system functions such as mounting local filesystems, activating swap device, setting udev, and so on. Sometimes, you don’t need some of the functions available in rc.sysinit, such as LVM and encrypted filesystem (at least, I don’t). What you can do is removing the “if” statement that calls the function you don’t need. Or better, just comment it out (use “#” in front of the if…fi statement). One example, I don’t use RAID, so why should the system bother to check if I use RAID? Therefore I comment the if statement that contains it.

# If necessary, find md devices and manually assemble RAID arrays
#if [ -f /etc/mdadm.conf -a "$(/bin/grep ^ARRAY /etc/mdadm.conf 2>/dev/null)" ]; then
#    # udev won't create these md nodes, so we do it ourselves
#    for dev in $(/bin/grep ^ARRAY /etc/mdadm.conf | /bin/awk '{print $2}'); do
#        path=$(echo $dev | /bin/sed 's|/[^/]*$||')
#        node=$(echo $dev | /bin/sed "s|^$path/||")
#        minor=$(echo $node | /bin/sed 's|^[^0-9]*||')
#        [ ! -e $path/$node ] && /bin/mknod $path/$node b 9 $minor
#    done
#    status "Activating RAID arrays" /sbin/mdadm --assemble --scan
#fi

Udev tweaks

Tweak1. We can speedup udev loading time, by starting it earlier in the boot process. If we look at /etc/rc.sysinit we can see this fragment around line 81:

...
stat_busy "Starting UDev Daemon"
/sbin/udevd --daemon
...

and this fragment around line 125:

...
stat_busy "Loading UDev uevents"
...
/sbin/udevadm trigger
/sbin/udevadm settle
...

Let’s move the udev daemon trigger right after the daemon itself is loaded. This will give it some time to finish what it’s doing before getting settled. Also, give the settle command an ampersand so it finishes its job in the background. The finished fragment would look like this:

...
stat_busy "Starting UDev Daemon"
/sbin/udevd --daemon
/sbin/udevadm trigger
...
stat_busy "Loading UDev uevents"
...
/sbin/udevadm settle &

This is like playing catch-up, this is a little bit dangerous since there’s a possibility that a module which is needed not already loaded when a daemon requests access to the particular hardware. This might be the network interface or sound card. But, I haven’t had any problem with this tweak, and I have booted so far without problem.

Tweak 2. Udev, by default, uses it own program to load modules, which is /lib/udev/load_modules.sh. We can improve the modules loading speed of udev by using modprobe instead. Make a copy of load_modules.sh, and then replace it with a symlink to /sbin/modprobe

# cd /lib/udev
# mv load_modules.sh load_modules.sh.backup
# ln -s /sbin/modprobe load_modules.sh

There is one drawback, though. You’ll lose the ability to blacklist modules from rc.conf. Now, you must enter the modules you want blacklisted in /etc/modprobe.conf, which looks like this on my system:

blacklist pcspkr
blacklist soundcore
alias net-pf-10 off

Inittab tweak

We can force the system to immediately load the Virtual Console once the init level is reached. This will enable you to immediately use the Console while the modules are still loaded in the background. We just need to replace “wait” with “once”. It’s much better if autologin feature is enabled (via mingetty). If you’re the only user, why bother logging in? My /etc/inittab looks like this

...
rm:2345:once:/etc/rc.multi
...
c1:2345:respawn:/sbin/mingetty --autologin prasetya vc/1 linux
...

Optional: Compile a custom kernel

You can compile a kernel that’s suitable for your system, stripping out unneeded stuff and make several device drivers builtin instead modular. This will give you some advantages: Less bloat, and faster booting. Compiling the current kernel is super-easy in Arch Linux. For this, you need ABS (Arch Build System).

# vi /etc/makepkg.conf
# pacman -Syu
# pacman -S abs
# abs
$ cp -R /var/abs/core/kernel26 ~
$ cd ~/kernel26
$ vi config
$ vi PKGBUILD
$ makepkg -i

Step 1 means, edit file /etc/makepkg.conf and add custom CFLAGS according to your CPU type. The list is here. This is to enable CPU specific code optimizations.

Compiling a custom kernel only give me 1 to 2 seconds improvement. It might not quite worth the time wasted on it (about 1+ hour of configuration + compilation), but yeah, I want that extra seconds. And so I give in to the temptation of the dark side :). If you decide to upgrade the kernel you’ll lose that optimizations, unless you recompile it with the new code. Given its high maintenance cost it’s only advisable for at least intermediate users (and curious ones). But, if just for kicks, why not? You’ll also learn a thing or two, by the way.
Optional: Recompile the entire system

There’s a script in AUR (Arch User Repository) that enables you to mass-recompile every installed package on your system from source using ABS. This, in logic, will give a more optimized binary for your computer, which in turn will make everything faster. I personally haven’t tried it yet. It’s similar to FreeBSD’s make buildworld/buildkernel command. The script name is pacbuilder, here.

Arch Linux is not originally designed to be mass-recompiled by the user, so the advantages of this script still needs to be proven. I personally wouldn’t want to use this (for now), I’ve had enough of similar process on FreeBSD.

Anyway, you’re bound to recompile each new packages once they hit repo if you use this method. I think it’s cumbersome, if you decided to recompile every new package that is. Anyway, it’s Arch. It’s already very fast. Why bother? But then, it’s up to you.
Other steps

Obviously, you can always improve the overall performance of your system by *upgrading* your system. This solution is the “easiest” and most feasible if you don’t like tweaking and have some $$$ to spend. Go find an extreme series motherboard, put two Quad Core Intel CPUs, buy several SATAII 10K RPM harddisks (or ultra expensive ultra fast SSDs) and put them in raid0+1 config, and buy the fastest, lowest latency memory cards. That’ll cost a fortune, but you’ll be like driving a Lamborghini Reventon (performance wise). Or, just stick to the tweaks :).
Conclusion

Why wait for some more seconds while your PC can do it in less? Tweak and refine your system. It’s one part (of many) of computing on Linux that’s very fun in practice, and gives you more knowledge while doing it.

代码: 全选


HOWTO: Arch Linux and modules

Are you using Arch Linux? And you are seeing modules all over the place for all kinds of crazy hardware you don’t even own? Then you’ve come to the right place!

First a word of reassurance: the modules loaded will not slow down your system at all, you will only waste several hundred kilobytes of RAM. But the output of lsmod does look nicer without the modules, and the system boots a little faster without them. But beyond these considerations there is very little to be gained in terms of speed during normal operation, by making the modules disappear ;-)

Think back to when you installed Arch. At some point during the installation you may have been asked to edit a few configuration files, but we are interested in one file in particular: mkinitrd.conf

The mkinitrd.conf file is the configuration file used by the program mkinitrd, which is short for “make initial ramdisk”. I am not going to complicate matters by explaining why you need a ramdisk, but if you’re going to use one anyway, it might just as well be optimized, right?

NOTE! ==> Editing the ramdisk may render your system unbootable, so it is wise to make a fallback entry in /boot/grub/menu.lst that uses the image called /boot/initrd26-full.img This ramdisk image will load every module it can and thus ensures that you will allways be able to boot your system in case you make a big mistake when modifying the normal /boot/initrd26.img

Right, now let’s start with the tweaking:

   1. Open /etc/mkinitrd.conf read the comments and then disable all the subsystems, except the subsystem you need. You need IDE if you got an ide disk. You need SATA if you got a sata disk. Need I go on? The only subsystem you must NEVER disable (unless you know what you are doing) is the filesystem subsystem. So DISABLE_FS=1 would be a VERY big mistake. Don’t do it! Don’t even look at it! Promise? Splendid! Indeed. Well, why don’t you move on to step #2.
   2. The next option is AUTODETECT. It is experimental but don’t let that fool you, it works just fine. You enable it like this: AUTODETECT=1 And now you may proceed to step #3.
   3. I also found it necessary to specify the filesystem I use, to prevent the ramdisk from loading modules for XFS, ReiserFS and JFS (I only use Ext3). This is accomplished by configuring the FILESYSTEMS option like this: FILESYSTEMS=(”ext3″). You will no doubt be clever enough to figure out that you need to specify what filesystem you are using instead of blindly copying my example. Now you can save mkinitrd.conf and close the editor.
   4. Finally, we execute the command mkinitrd auto –show in order to create and install the new ramdisk

      And that’s really all there is to it. Simple, isn’t it? Quickly reboot and see what a difference this makes! Now that you’ve taken care of a veritable the maelstrom of filesystems and hostcontrollers, things should look a lot cleaner. But there may still be a couple of other modules you want to prevent from loading (such as the pcspkr module which enables the annoying pc-speaker). If you want to do that, you need to open /etc/rc.conf in an editor and add modules you don’t want to see in the output of lsmod to the MOD_BLACKLIST=() array. This is what I have in my array, for example: MOD_BLACKLIST=(pcspkr joydev gameport) If you are not sure whether you need a module, just google for it, or experiment with putting it on the blacklist.

      Good luck and have fun!

千帖户,享有论坛特权!
头像
leeaman
帖子: 30702
注册时间: 2007-02-02 18:14
系统: debian sid
送出感谢: 1 次
接收感谢: 23 次

Re: arch linux 启动优化(非wiki ,转)

#2

帖子 leeaman » 2009-03-20 17:04

English :em20
醉了星星,醉月亮●●●●●The Long Way To Go(*^_^*)
头像
adagio
论坛版主
帖子: 22109
注册时间: 2008-02-17 23:47
来自: 美丽富饶的那啥星球
送出感谢: 7 次
接收感谢: 74 次

Re: arch linux 启动优化(非wiki ,转)

#3

帖子 adagio » 2009-03-20 17:12

leeaman 写了:English :em20
还以为你翻译出来了 :em20
明天就换大三八!
——8核CPU、8G内存、8T硬盘……
8卡交火,80寸大屏放8个……
IPv8的光纤要8条……

---------------------------------------------------------------------------------
[图片版]新手当自强(续)FAQ
[新手进阶]挂载、fstab、调整linux分区
[图片版]E17桌面环境配置手把手
头像
xiooli
帖子: 6956
注册时间: 2007-11-19 21:51
来自: 成都
送出感谢: 0
接收感谢: 3 次
联系:

Re: arch linux 启动优化(非wiki ,转)

#4

帖子 xiooli » 2009-03-20 17:25

20s左右,够快了。
头像
john.wu
帖子: 1006
注册时间: 2007-10-18 17:40
送出感谢: 0
接收感谢: 0

Re: arch linux 启动优化(非wiki ,转)

#5

帖子 john.wu » 2009-03-20 17:27

adagio 写了:
leeaman 写了:English :em20
还以为你翻译出来了 :em20
We will be working entirely on English so if you’re not comfortable with it, go get some coffee and watch movies instead.
:em05

千帖户,享有论坛特权!
头像
adagio
论坛版主
帖子: 22109
注册时间: 2008-02-17 23:47
来自: 美丽富饶的那啥星球
送出感谢: 7 次
接收感谢: 74 次

Re: arch linux 启动优化(非wiki ,转)

#6

帖子 adagio » 2009-03-20 17:45

我只喝茶看毛片的 :em39
明天就换大三八!
——8核CPU、8G内存、8T硬盘……
8卡交火,80寸大屏放8个……
IPv8的光纤要8条……

---------------------------------------------------------------------------------
[图片版]新手当自强(续)FAQ
[新手进阶]挂载、fstab、调整linux分区
[图片版]E17桌面环境配置手把手
头像
leeaman
帖子: 30702
注册时间: 2007-02-02 18:14
系统: debian sid
送出感谢: 1 次
接收感谢: 23 次

Re: arch linux 启动优化(非wiki ,转)

#7

帖子 leeaman » 2009-03-20 19:13

呵呵书读得少啊 :em01
醉了星星,醉月亮●●●●●The Long Way To Go(*^_^*)
头像
qiang_liu8183
论坛版主
帖子: 10670
注册时间: 2006-09-10 22:36
来自: 北京
送出感谢: 1 次
接收感谢: 6 次

Re: arch linux 启动优化(非wiki ,转)

#8

帖子 qiang_liu8183 » 2009-03-20 19:27

老掉牙的文章了
看破、放下、自在、随缘、念佛
真诚、清净、平等、正觉、慈悲
头像
john.wu
帖子: 1006
注册时间: 2007-10-18 17:40
送出感谢: 0
接收感谢: 0

Re: arch linux 启动优化(非wiki ,转)

#9

帖子 john.wu » 2009-03-21 13:28

qiang_liu8183 写了:老掉牙的文章了

:em06

千帖户,享有论坛特权!
saiddy
帖子: 87
注册时间: 2006-04-15 23:44
送出感谢: 0
接收感谢: 0

Re: arch linux 启动优化(非wiki ,转)

#10

帖子 saiddy » 2009-03-21 21:20

15秒 和我差不多了
头像
cnshzj007
帖子: 685
注册时间: 2006-05-24 21:38
来自: 上海
送出感谢: 0
接收感谢: 0
联系:

Re: arch linux 启动优化(非wiki ,转)

#11

帖子 cnshzj007 » 2009-03-25 23:54

呵呵,我有时想要看清楚rc.d中有哪个是DONE的,哪些是FAIL的,所以还希望启动慢一些,所以我是把openntp做GDM之前的最后一个,嘿嘿,那就有足够时间看清楚rc.d中的启动情况了,有没有更好的方法?
上次由 cnshzj007 在 2009-03-26 0:06,总共编辑 1 次。
我只是一个ARCH的FANS,来自RH和UBUNTU的滋润!
头像
hcym
帖子: 15634
注册时间: 2007-05-06 2:46
送出感谢: 0
接收感谢: 2 次

Re: arch linux 启动优化(非wiki ,转)

#12

帖子 hcym » 2009-03-26 0:01

俺只能持续15s

医生说再不能优化了


:em03
回复

回到 “Arch发行版”