Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So, I've got a zippy little kernel carrying my all-purpose desktop around on its 1.6M foot, the performance is great, the stability can't be beat, and I'm not lacking any features or functionality.
The problem is, my kernel takes up to 15 seconds to load, and it's not because of slow hard drive reads.
I'm not sure what causes this, though I see what seems like quite a handful of redundant hardware detection. Hello - isn't that the BIOS' job???
I'd really like to rig up the kernel to fly through the boot process, either by taking its information from the BIOS and believing it, or just skipping any hardware detection altogether and following a static boot process.
Are either of these concepts doable?
Also, could someone explain to me the sorts of things that actually drag down the boot time like this? I believe I'm on the right track with the hardware detection bit, but I'm going on intuition so I'm probably rather far off.
If you're using a regular distro, then it probably is designed to do auto-detection, and if it takes 15 seconds to load a kernel that's then going to be "up" for the next three months non-stop, who cares?
On my system, which is Gentoo, I've done all of the hardware-configuration in advance, setting-up all of the options needed by all of my particular hardware in advance. No "detection" is therefore needed. The systems still take about 30 seconds to get completely up-and-running, and once they're "up" they remain booted-up for months on end.
"It can be done," but perhaps you should seriously contemplate the worthiness of changing your status-quo. Does it have a return on your investment of time and hair-follicles?
I run Gentoo as well, and have hardly managed to cut the init time down to 36 seconds with initng (48 with the default init.) I do leave my computer on much of the time, though I am more then justified in wanting to reduce my boot time, primarily because I plan on dual-booting Windoze so I can make use of Photoshop and some other software.
I have stripped my kernel down to support only the hardware I need, though I am not familiar with how to prevent unnecessary work from being performed at boot time.
I really enjoy this sort of thing, so I'm not too worried about losing my hair over it, but any help on where to start would be much appreciated.
My kernel boots in 10 seconds, full boot time is about 35. I'd like to make it faster though. Does anyone know of any tips? I'm using the lattest (git) version and have it configured for my kernel, ie no hardware drivers that I don't need. Also everything is built in.
Code:
# lsmod
Module Size Used by
nvidia 7796008 26
There's some kind of bios handoff bug that takes like 5 seconds. It spends a lot of time configure USB devices as well. My keyboard uses USB 1.1 or I'd get rid of one of the usb drivers.
I'm not sure what causes this, though I see what seems like quite a handful of redundant hardware detection. Hello - isn't that the BIOS' job???
No. It's the OS job. BIOS stands for "Basic Input/Output System", and it should just contain a few kbs of code that let the machine initialize enough stuff to be able to boot and pass the control to the OS.
The BIOS can't do everything that an OS can do, and can't deal with all the hardware like an OS can do. Otherwise, we wouldn't need any drivers at all, and we would just use BIOS calls from all OSes. Even more important, BIOSes usually have bugs and limitations, relying in the BIOS info would bring us more trouble than good. For example, the (in)famous limitations on the hard disk capacity that we have been seeing for quite a long time. Windows used to trust the BIOS, and hence you ended with unused space in your brand new hard drive. Linux, on the contrary, do what needs to be done and ignore the ignorant BIOS, giving you full access to your hardware.
Quote:
I'd really like to rig up the kernel to fly through the boot process, either by taking its information from the BIOS and believing it, or just skipping any hardware detection altogether and following a static boot process.
I don't exactly get the idea. If a driver is not in your kernel, then the kernel shouldn't be looking for the relevant hardware either. So, you just need to strip down your kernel. If you already did that, then the only thing you can try is to identify the steps where it spends the most time, try to debug/profile them and patch them for faster performance.
You might want to check coreboot, formerly known ad "linuxbios". That would be the fastest you can get. By putting the linux kernel into your BIOS chip you completely bypass the BIOS and boot right and straight into your OS from the moment you press the power on button on your case.
Quote:
Originally Posted by sundialsvcs
A lot depends upon which "distro" you are using.
Not really, unless that distro uses a revolutionary patchset that completely changes the way that the kernel boots. Note that the OP is talking about the kernel boot time, and not about init and later stages.
A kernel that has been built statically will probably be a bit faster, but nothing noticeable. Overall if the modules are contained in an initrd, because they will then be read from ram and it will be just almost as blazing fast as if they were inside the kernel.
Must admit I subscribe to the "who cares" school of thought re boot time. I just go make a coffee.
Regardless, have a look at this - especially segment 1.6
Lol coreboot sounds awesome. My motherboard (p5q pro) isn't supported though. It does have this expressgate thing that boots a very small linux in under 5 seconds. You can unsquash the images it uses and modify it yourself but you can't put an entire distro on it. I tried doing a debootstrap, even a chroot inside the main linux it boots, but I cant seem to get it working. Any apt-gets would be temporary of course but theoretically you could build a system, copy it to a HD, and squash that.
Quote:
Originally Posted by syg00
Must admit I subscribe to the "who cares" school of thought re boot time. I just go make a coffee.
I don't know it's fun :P?
Quote:
Regardless, have a look at this - especially segment 1.6
Compiling it now. I've been watching a timer thing you can enable in kernel hacking to see what's taking time. I'll see what this thing can do; it sounds nifty, being able to make a graph and everything.
Lol coreboot sounds awesome. My motherboard (p5q pro) isn't supported though. It does have this expressgate thing that boots a very small linux in under 5 seconds. You can unsquash the images it uses and modify it yourself but you can't put an entire distro on it.
You shouldn't need to. You would only need to make sure that the kernel in that image supports all the hardware you need to boot and find a way to specify the root partition, then use your linux partition in your hard disk instead of the one in the image. It *should* (TM hehe) work. But I can't be certain since I don't have the thingie to experiment with it myself.
I didn't even know about this express gate thing, so I will research a bit about it. If I can find something interesting I'll let you know.
I think it selects the OS internally. Like when you flash the bios (there's no kernel line or anything like that). It has a utility that auto-searches for squashfs files in the directory and runs an init script inside each one.
Now that you mention that, however, it might be possible to modify the first init script to physically mount a partition at / and then execute the init script on that partition (while removing all the other squash files so it never executes the scripts on them). That or you could do the thing that slax livetools (whatever it's called) does; mount it somewhere else, chroot, and executie init.
I think I tried to actually mount my gentoo install once but it's on reiserfs and iirc the thing doesn't even have ext support (it does have ntfs support though). I gave up using it several months ago primarily because I couldn't access my main linux or data drives. It was kind of fun while it lasted but even being able to modify the filesystem yourself it still has its limitations (like the video drivers couldn't run at a very high screen resolution). I think asus needs to open up their utility because it's entirelly possible to boot a full linux install using expressgate. It might not boot in 5 seconds but expressgate skips all the bios stuff which on my board takes something like 10 seconds to complete.
Wow I've cut ~13 seconds off my boot time. I did some research about the ehci bios handoff and found the option in my bios to enable the handoff. That was costing me 6.4 seconds right there. I also removed my non-root drives from /etc/fstab and wrote another script to mount them (without fsck). Even if you want to check all your drives every time you boot it'd probably save you a lot of time to write two scripts. Almost everything depends on fsck, because they need / mounted, and you end up wasting time fscking non-important drives when the rest of your system could be booting.
I have xdm starting at boot with all the /sbin/telinit commented out. By the time I log in and xfce4 is done all the other rc stuff is complete.
The longest kernel call is ahca_init. I'm going to look at all the ahca options and see if I can find ways to make that shorter. If I do I'll post updates. From what I'm seeing though there isn't a whole lot of imporvement possible from the kernel side. I already have an optimized kernel of course but 3.57 seconds just isn't that long compared to the total 22 second boot time.
I also removed my non-root drives from /etc/fstab and wrote another script to mount them (without fsck). Even if you want to check all your drives every time you boot it'd probably save you a lot of time to write two scripts.
Maybe there's something that I am not considering. But as far as I know, if you set the sixth field in fstab to "0" (zero) for a given volume, it will not be checked.
Maybe there's something that I am not considering. But as far as I know, if you set the sixth field in fstab to "0" (zero) for a given volume, it will not be checked.
I'm going to assume that it does (will find out next reboot). I was wondering why such a feature didn't exist already because it seems like something that should be implimented.
From my experience and the fstab man page, it should work. If all you want is to bypass fsck that what it does. No need to say that you are the one to keep the integrity of your file systems manually, since they will never be checked unless you do it manually.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.