login
Search
Well, I have a machine that need ata_piix module. I built that module and SCSI related module inside the kernel. So, It no longer need initrd anymore. It boot 2.5 seconds faster without initrd than it does with initrd. But, I don't know if it works better than kernel with initrd. So, I'm looking forward for your respons.....
Happy hacking....
Do you mean that you
Do you mean that you recompiled kernel with ata_piix support ?
What I am thinking is, having the modules loaded through initrd is better in terms of modularity. The reason is, if you get a new fix for the ata_piix, you do not need to recompile the kernel and get a new image - rather you can just modify the initrd and one reboot is enough :-) any other thoughts ? and again your system is a server or a desktop system ?
piix.ko performance problem
On one laptop, piix.ko in 2.6.23 was making this laptop run like it had a 286 processor instead of a P4. I investigated and found various distros. were loading the newer ata_piix.ko. I do not use initrd for trying to build a generic kernel, instead I build statically into kernel what will boot all the machines I usually encounter. Initrd's have many other uses (where the initrd IS the rootfs rather than mounting a rootfs on disk and transferring control) other than loading rootfs filesystem and hardware modules. They are used for that purpose by distros. because they build kernels where every single check box that can be is set to "m" (build as module), because if they leave anything out, people will whine "my hardware doesn't work on distro XYZ!", but unless you are building a distro. that approach is non-optimal.
If you gunzip and loopback mount the initrd from any major distro. you will find some really junky code that doesn't meet my standards to be on my system. Sloppy scripts, extra junk files lying around, etc..
I fail to see your 'modularity' concept. To tailor a kernel exactly to a machine, I take a similar one (NOT a distro one) and run "make menuconfig" to modify some check boxes, then run "make" followed by "make modules_install install". The "make install" runs in my case LILO, and after one reboot I am running the new kernel. That has nothing to do with initrd. It is quite difficult to get modules from one build of a kernel to run with another build, even if it is at the same level, i.e. 2.6.23.12. This is by design to frustrate those short sighted businesses who would like to ship Windows-style binary .ko or .o modules, after which they would state "we don't support kernels above 2.4.21, 2.6.5, ...". For example, after ANY kernel config. change, I always have to rerun "vmware-config.pl" to rebuild the VMWare interface modules. The main reasons for loading modularly are: 1) not wanting to allow a static module to run its init routines (to see if it should load) because it might crash and these init routines may take a little extra time, 2) the ability to load a particular driver when multiple drivers can handle a device (i.e. ata_piix.ko rather than piix.ko when both are built as modules), 3) not wanting to load support at all for a device (i.e sound card support on a server), 4) static modules requiring some memory support in the base kernel image that cannot be released.
Not sure about server vs. desktop question. My take on that is that for a server it is worth the time to optimize the kernel exactly to the hardware, i.e. picking exactly the right processor, i.e. K8 or P4 rather than running a distro-generic "i686" kernel which would be Pentium-Pro level, and actually not loading drivers for unwanted hardware (no udev, or modify its rule set that wants to load every driver for everything it finds on your system). Having to run a generic so-called "Enterprise" kernel with all kinds of "smp=no apic=no hpet=disable" junk kernel parms really indicates a MSCE-- (or even just A+) level technician is maintaining the server, who would have no concept of how to rebuild the kernel properly for that system.
Probably not initrd issue
There are two competing drivers that can handle this chipset: piix.ko and ata_piix.ko. It's likely that when you were using an initrd that udev, etc. selected the older, supposedly more stable piix.ko rather than the newer ata_piix.ko. I find the older piix.ko stable driver seems abandoned, while the new one which in kernel help claims to be "experimental on PATA/stable on SATA" works much better (PATA drives appear as sda rather than hda with ata_piix and the other new libata-based drivers). It was not just at boot time, but hard disk performance was increased during post-boot operation.
By building ata_piix.ko into the kernel, you took udev's ability to load the other driver in the initrd away since your device was already claimed by ata_piix when udev tried.
There is generally no harm
There is generally no harm in not using initrd. Distributions do make use of initrd because they want to avoid committing large amount of drivers into kernel RAM (which can't be swapped out). You should see no ill effects.
What I mean
I mean a better perfomance in booting and in doing "its job as a kernel". I think kernel with no initrd boot faster because it mount the filesystem directly instead of mount the "initial filesystem" first. My machine is a laptop with Core 2 duo T5600 and Intel 945GM chipset
Depends on mkinitrd
If mkinitrd generates a very small initrd that contains, for example, a very small busybox, and in your case ata_piix.ko, perhaps ext3 modules, and just enough to get the system going, there is no way that should take 2.5 seconds to load the initrd into RAM, gunzip it, run trivial hardware autodetect based on PCI ids, and switch control to the rootfs on the hard disk. However, many initrd's instead have a "rescue disk" built in and extra modules not just for your hardware, so in that case it is easy to see where 2.5 seconds is wasted loading a bloated initrd into RAM and gunzip-ing it, before anything starts to happen.