great job. gdm shows really fast. but of course it takes a while for login. lÃr, 13 11 2004 kl. 21:24 -0500, skrev David Zeuthen: > Hi, > > So I had a brief look at shortening startup/login time and tried > disabling rhgb in favor of starting gdm early. It looks pretty > promising; here are some wall-clock numbers from two runs of each > configuration: > > | gdm_early | rhgb+gdm | > ----------------------+------+-------+-------+------+ > GRUB timeout | 0:00 | 0:00 | 0:00 | 0:00 | > Starting udev | 0:13 | 0:13 | 0:13 | 0:14 | > HW init done | 0:25 | 0:25 | 0:26 | 0:26 | > rhgb visible | N/A | N/A | 0:36 | 0:35 | > gdm login visible | 0:43 | 0:44 | 1:25 | 1:26 | > gdm login entered | 0:52 | 0:52 | 1:31 | 1:32 | > GNOME banner visible | 1:13 | 1:14 | 1:40 | 1:41 | > Nautilus Background | 1:33 | 1:32 | 1:51 | 1:52 | > Panel visible | 1:43 | 1:43 | 2:02 | 2:02 | > HD activity off | 1:59 | 1:56 | 2:13 | 2:14 | > > The milestones should be pretty self evident. This is on a stock FC3 > system running on a IBM T41 1.6GHz (running on AC power), 512MB RAM > without any services manually disabled. > > In addition to starting gdm early, the modifications also start up a few > services, D-BUS, HAL and NetworkManager, that is critical to the GNOME > desktop. > > Some random thoughts/observations: > > - We get the gdm window 40 secs faster > > - The 12 secs from "Starting udev" to "HW init done" can be mostly > shaved away/run in parallel > > - Kernel bootstrap time (13 secs) can probably be much shorter > (that's what some kernel guys say anyway) > > - With this hack we shave twenty secs of the booting time (e.g. from > GRUB until you can use your PC) but booting still feels much quicker > because of the interaction with gdm in the middle (YMMV; e.g. placebo > effect etc.) > > - rhgb+gdm spawns an X server each which is sort of stupid and unsafe > (or so some Xorg guys tell me). This solution, per design, avoids > doing that > > - we don't get the kudzu screen nor the fsck screens or any other > console interactions. However, IMHO, such screens are not good UI > in the first place - we should instead have GUI replacemnts that > possibly notifies you when you log into the desktop session (stuff > like NetworkManager and HAL alleviates such problems for networking > and storage devices) > > - we don't get service startup notification, but, uhmm, is it really > useful learning that the "Console Mouse Service" or "Printing Sub- > system" have started? Instead, this stuff could just be put in gdm > > - it could be interesting to make /sbin/init own a D-BUS service that > gdm and other stuff can query and interact with. Could also be fun > to completely replace it with something a'la the SystemServices > prototype that Seth did last year; links > > http://www.osnews.com/story.php?news_id=4711 > http://www.gnome.org/~seth/blog/2003/Sep/27 > > - Could be interesting to instrument the kernel with some pagefault > counters etc. and attempt do more readahead on e.g. the GNOME libs > (both Windows XP and Mac OS X does all that; I think we do too but > I've been told it can be improved) > > So, anyway, I think it could be interesting to discuss starting gdm > instead of rhgb. If you want to try out my crude hack, grab the file > here > > http://people.redhat.com/davidz/newinit.sh > > put it in on your system as /newinit.sh, chmod a+x it and change this > line /etc/inittab > > si::sysinit:/etc/rc.d/rc.sysinit > > to these two lines > > #si::sysinit:/etc/rc.d/rc.sysinit > si::sysinit:/newinit.sh > > and you should be set to go! If it breaks you get to keep both pieces; > e.g. try this at your own risk [1]. > > Cheers, > David > > [1] :if it doesn't work you can boot your kernel with init=/bin/sh, do a > 'mount -n -o remount,rw /' and edit your /etc/inittab file to point to > the original sysinit. > > -- Fedora-desktop-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-desktop-list
