Wow! I'm very impressed zache! Want to see how much faster you can make this! Well done!

There is a small latency decrease (faster booting) with Intel's C Compiler over GCC. This is mainly due to SSE vectorisation. Can't get it to compile a kernel yet, however it will help with kdrive and finit-alt. If you have problems with either - drop me a PM as it is mainly just header's for ANSI compliance.

A Realtime kernel on the EEE is faster to boot - but not with wireless. This is mainly due to the ath5k and madwifi-ng driver not supporting realtime.

Adding "i8042.dumbkbd=1" to the kernel line in grub helped with the synaptics driver jamming up the kernel. I also add "force-hpet" - but HPET is not as quick to load as old style RTC - so until tickless becomes the norm (i.e. faster) it may be better to do things the old fashioned way.

The Gallium project will (hopefully) replace MESA and improve acceleration - it is much smaller codewise and should boot quicker - I personally lack knowledge enough to get it working, but it looks very promising.

Good luck - and can't wait to see your 9 second boot into X.

Metalshark: I wonder if (we don't care if configuration is usable ) time could be under 5s. Basically  time is (POST + Bootloader +Kernel)  5s or 6s + (fastinit+Xfbdev+blackbox) 1 or 2 sec .  So question is how we can make our kernel boot faster or init start earlier.  And if so, then userspace will follow

Usable configuration for 5/6sec boot could be: 1.) boot fast as possible to X, 2.) ask pin/login 3.) do rest of boot at background when UI waits human interaction and for user everything would seem to be instant.

But right now i am installing ubuntu to test how easy or hard is implement finit stuff  there, so next thing is slower boots for some time, but it is probaply more usefull than trying to boot eee in 5sec

btw: do anybody have any ideas how to get /proc/acpi/battery/BAT0 working when "boot booster" is enabled? Right now my battery just doesn't exist for linux if it is enabled and it somehow renders setting to unusable. Also does anybody knows if it works in windows?

Last edited by zache (2008-04-27 7:40:53 am)

The EEE's Celeron can't clock up or down dynamically - we can change the FSB's frequency and hi/low voltage option - and that's it. You can only save power by being idle (the power save scheme artificially inserts idle ticks). Hence tickless is a good idea. It's new though and therefore not as fast... yet.

Going down a laptop repair shop (lots in London) you can pick up a Pentium M 773 very cheaply and get it replaced (BGA processor replacement). It is capable of changing it's own speed and power requirements - without BIOS modding it'll run at a peak speed of 910MHz and if you're a light CPU user it'll save you battery life.

The only easy way to get really small boot times would be to copy of the idea of boot booster - but for the OS. For instance if we meddle with the suspend to disk code, take a snapshot of X loaded (before the background services) then load it from disk everytime the EEE is turned on. Need UDev and HAL to be ultra polished though - to deal with devices being detected upon boot up.

Minix can boot up in less than 3 seconds - so there is hope yet :-D

Hmm, based on your bootchart 21secs is actually very good (kind of that my guess is that  my 2G would boot slower with same configuration and Xandros/Debian). I wonder if it because Gentoo comples binaries for specific platform, 4G:s higher Mhz or because more memory than in my 512MB.

Anyway, from your bootchart. Udev takes lot of time at beginning of the boot and it delays all other things, so it would be first thing what i would optimize (I would probaply just background or remove it). Sourcejedi wrote that he has patch for Udev to speed things up and it could be more elegant solution. (see this thread)

Secondly i would check why hwclock is taking so long in bootchart (it looks something which can backgrounded)

Third thing is that the Xandros fastinit is so fast because it starts X basically fast as possible and runs rest init scripts (services.sh) paraller with X- Your system does basic init stuff first and after that it runs rest of the system (like X).

Though starting X earlier than system is ready surely breaks stuff, but it is kind of easily doable and doens't break things much (Xandros proves it). So if you want to test it you could start startx directly from initscripts and see if it starts or fails (and why). Starting X just before hwclock looks like good place for first test.

Also this thread is maybe intresting. ( btw Finit / fastinit isn't really that much faster than doing same stuff from normal init, so switching normal init / openrc to finit for speed doesn't help. The Finit's big thing is that if you are breaking your system MUCH, it allows to change system in a ways that normal init doesn't allow)

Last edited by zache (2008-06-06 12:35:42 pm)

Yeah, i had same issue, though with puppy linux which uses normal init. I solved it with switching to finit, but before i did it i noticed that X loses keyboard focus if X starts before parent script dies (or if it starts before init spawns terminals?). I never tried to diagnose why it really loses keyb though and init scripts what i used in my puppy linux were way simpler than your openrc scripts.

While going through dmsg last night, I found something interesting. (If it's something you've already considered, or doesn't apply, please ignore

The Intel hardware random number generator module (intel-rng.ko) attempts to load fairly early in my bootup process; and I noticed it takes about a second before it fails with:
"intel_rng: FWH not detected"

That process of checking and failing takes about a second.

Might be worth a shot to add "blacklist intel-rng" somewhere under /etc/modprobe.d
or even just delete the module itself.

Hope this helps