On Mon, 21 Jan 2008 11:59:36 +0000 Andy Green <[EMAIL PROTECTED]> babbled:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Somebody in the thread at some point said: > > > | sexy things that live in rc5 (X) until expensive stuff like udev (18s) > > > Check your kernel defconfig, it probably has a gazillion virtual > > consoles, decrease those to like 8 and udev starts up almost > > instantaniously. Related to that, more recent udevs use a different > > method to create devnodes which is said to be faster. > > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_NR_TTY_DEVICES=4 > > But point taken, I bet udev can be optimized down... there's alot of > stuff in /etc/udev.d/rules or whatever it is that talks about hardware > that isn't really going to ever appear, maybe that can help too. in general everything we do at boot can be optimised down to some extent - we just need to tackle it 1 thing at a time. even if we launch x early- how soon will it be until they can make a call? that is a slight problem of deferring init until after parts of the ui are up. we can get around this via psplash - which we already do, BUT psplash can be very static and often wont do anything for seconds on end - bar doesn't move. you wonder if it has hung. preferably we need it to animate something all the time so you know something is alive and kicking. other than that nixing all the silly things we do (like massive bash scripts and functions that probably should be C programs as putting lots of logic in bash is SLOOOOOW. last time i did a speed test bash was about 31,000 TIMES slower than equivalent compiled C in doing things like if [ x ]; then blah; else blah2; fi, interspersed with a bit of string and number math. just a quick hard-facts check. 1. alsa-state - keep it. will need for starup audio bling thing so user knows things are alive and working 2. dropbear - is started early - we can delay this until long after UI is up. 3. apmd - can wait until ui is up and kicking as well 4. dbus - keep. will need for full ui 5. syslog - call me a heretic, but i disabled syslong on my laptop to avoid iot writing stuff to logs i will never read and eating up disk space, disk IO , disk wakeups and so on. why do we need syslog? (sure for debugging - but for a target consumer device? if there is no way for the user to inspect the logs from the gui... why have them?) 6. avahi-daemon - we can delay this until we bring up any form of network interface. that can be delayed imho 7. bluetooth - keep it. would need for early-stage calls via headsets etc. 8. gsmd - keep it. duh! 9. pulseaudio - keep it. same as alsa above 10. usb-gadget - delay it until after gui is up? 11. rmnologin - if we delay dropbear, does it matter? remove it. 12. xserver-nodm - this is where the rest of the bootup pain begins. its a long long long time between here and a gui you can actually do things with a quick timing test (after the kernel has done scanning all the flash forever) is about 50 seconds/ that's the sysv init stuff here that psplash hides. it's about 20 seconds to go form x up to gui actually there. so we need to address this in 2 parts. sysvinit etc. is only 1. the actual user xsession is another. so /etc/X11/Xserver needs some love and attention too. and thus /etc/X11/Xsession and /etc/X11/Xsession.d/* ... let the can of worms roll on. -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
