"Mark Haney" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 12 Nov 2008 15:43:35 -0500:
> [EMAIL PROTECTED] wrote: > >> I allready took everything out of my kernel but is there a big >> difference with modules or buildin's ? And X allready starts at boot. >> >> And why shouldn't I use genkernel? >> > I don't know about moving X, but this is a thread I thought about > starting yesterday so this is very timely. I'll look at X to see how > things are affected. I'd suggest /not/ putting X in the boot runlevel, unless you're one of the "It's not booted until I have a nice pretty GUI with a pointer to click stuff because I don't know how to use the command line" folks, and on Gentoo at least, those folks should be comparatively rare, since Gentoo never has been and is not now designed for folks who aren't willing to be their own admins, including those scared of the command line. There's other distributions that are a better fit for people who prefer to let someone else do the command line and admin stuff. Here, even tho I'm on an always-on Internet connection, I boot to initlevel 2, nonetwork, and without X as well. I start all services (including named and privoxy, which are normally of use only when the net's up, but don't require it; they start fast enough) except ntp/ntp- client and the network they depend on. This way, if I'm just doing local admin work, say backups, or doing a git-bisect/build/install/reboot cycle while debugging a kernel regression, I get a faster boot, and don't end up constantly connecting to the NTP servers I sync to, every time I reboot. I have one each of the gpm triple-click functions set to init 3 (network) and init 2 (nonetwork) so I can switch between them without having to sudo. That way, if I AM going to be starting X (or doing something else that needs the network and Internet connection), I can log in as my regular user, and triple-click to start the network and time services. Then I run startx as my regular user if that's what I want to do. Actually, I have a couple scripts that set XSESSION appropriately and take care of a bit of additional housekeeping for whatever X environment I'll be running (called k3 and k4, for the kde3 and kde4 environments I run), then invoke startx. I have it setup so I can source these scripts and it'll log me out at the text VC as it starts X and whichever KDE, so I don't have the unused text login sitting there wasting resources. So I don't have X in any runlevel, DEFINITELY not in the boot runlevel, as I start it from my text login using a script that calls startx. Of course, some folks may indeed want X started in their default runlevel, which is fine, but putting it in boot, so it runs for every runlevel except single, just doesn't make sense to me, because there are valid tasks one may wish to do at the text console, in which case starting X just wastes startup time and computer resources. As for fast boots... Really, here, the BIOS initialization takes longer than anything else. Here are some observations and optimizations I've made. * Under some circumstances, fsck can take a significant amount of time, particularly if there are a lot of partitions to fsck and mount, but since I use reiserfs, which doesn't really do more in a boot-time fsck than it does automatically at mount anyway (if there's something damaged beyond what it can automatically fix at mount, you gotta run the longer fsck with it unmounted, anyway), so I just set the fstab fsck field to 0 for all partitions and let reiserfs do its thing at mount. * As already mentioned by others, initramfs/initrd take significant additional time, as do loading modules. Therefore, build into the kernel (not as modules) all your normally loaded modules and drivers, and don't run an initramfs/initrd unless you have special case needs that require it. Additionally, don't build stuff that's never loaded at all, and build as modules (and don't load by default) stuff that's only occasionally used. As examples, I build fat/vfat, ext2 (and no ext3 at all, my system's all reiserfs as mentioned above), floppy, loop, and usb- storage as modules because I don't use them much of the time. * With stable baselayout (1.x), the parallel startup didn't work too well. It works much better with ~baselayout (2.0.0) and openrc (0.3-rc1 is what I have currently), but it's still off by default, and there may be a few dependency tweaks necessary to get everything loading in the right order, depending on your system configuration. Of course, baselayout 2 and openrc are quite different than the old baselayout 1 as well, so if you upgrade, be prepared for a decent amount of reconfiguring and perhaps some tweaking before you get your boot sequence running smoothly. There are definitely reasons it's not marked stable yet, and probably won't be any time in the real near future, either. Openrc in particular is still under heavy development and just isn't ready for stable yet, and since baselayout 2 needs it... So, for those willing to brave the not yet necessarily smooth upgrade path, baselayout 2 and openrc can be MUCH faster, but there's still some definite admin cost associated with that choice. * It helps to have plenty of memory, 1-2 gig per CPU core to work with, and multiple CPU cores. * Once you get the memory and multiple cores, or even if you've a relatively fast single core, a single spinning disk REALLY bottlenecks a boot, particularly with parallel turned on. An SSD based system is one option, but here, I went with kernel/mdp based RAID instead, four-way SATA based RAID-6 for my main system, which means two-way striped, two- way parity for hard disk redundancy. It really does make a noticeable difference, both in boot-time, and in system responsiveness under heavy I/ O load. The kernel really does do a good job managing parallel read/ write, if it knows it's working with multiple spindles as it does when you are running kernel based RAID. Actually, the I/O bottleneck of a single spinning disk is probably the biggest slowdown in most modern systems. They have multiple CPU cores and ever bigger and faster memory, but that single spindle disk is actually far slower relative to everything else than it was a decade ago. (It is actually somewhat faster than it was back then, but everything else has improved by a factor of 10 or more while disk speeds have only about doubled, /maybe/ tripled, so if you are still tied to a single disk, that's now a BIG bottleneck.) * Make sure you're running the correct SATA/PATA/SCSI chipset drivers for your system. With SATA, as long as you have the correct drivers, the kernel is pretty good about enabling DMA at the fastest stable speed. If you are still running PATA, check that DMA is enabled and at the most efficient stable speed -- the kernel isn't quite as good about that on PATA/IDE. Particularly for PATA, you may need to merge hdparm, put it in your boot runlevel, and configure it appropriately to enable full speed I/O. I don't know enough about real SCSI drives to say anything intelligent about them, beyond the verify the chipset driver thing already mentioned. If you are running the wrong or generic chipset drivers, it almost certainly WILL negatively affect your performance, likely dramatically so! (If you really want to tweak your boot and you need hdparm to get optimal DMA, consider modifying its service dependencies to start BEFORE pretty much everything else, including the fscks for localmount and possibly even before the root fsck and remount r/w. Mounts and fscks are obviously pretty disk intensive, and if you can do that at full speed DMA instead of slower compatibility mode, it WILL make a difference. Of course, if DMA is the least bit unstable on your hardware, doing fsck with it enabled is a pretty good invitation to disaster, and the Gentoo default dependencies wait until everything's fscked and mounted before running hdparm, so if you screw with that and it breaks, as they say, you get to keep the pieces, but if you're a sufficient ricer, that's not going to do much to stop you...) * Do note that at least some of those blogs don't include BIOS initialization time (which as I mentioned above is the slowest bit here) as they figure it's not in their control. This was certainly the case for the 5 second Eee SSD netbook boot demonstration at, IIRC, the Linux Plumber's conference, according to comments on LWN. And of course that 5s was on an SSD, not a spinning disk drive. It's still pretty impressive, tho. * That said, there's often BIOS tweaks you can do to make that part faster. For those with floppies, for instance, disable the floppy check (and consider disabling it entirely if you don't use it much, you can always go back and enable it again if you need to) and set the BIOS to boot off the appropriate hard drive FIRST. The same goes for booting off of CD/DVD and/or USB devices -- disable booting from it and/or put the hard drive boot first, thus both saving boot time and providing yourself a bit of extra protection against boot sector virus propagation. Again, you can always change it later if you do need to boot from CD/DVD/USB. Netboot (PXE-boot) as well, disable that (and any associated network BIOS checks) unless you are using it. Of course, setting quickboot, thus avoiding the not so accurate anyway BIOS full memory checks and etc, is one of the first BIOS time optimizations, so much so I almost forgot to mention it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
