>> The initramfs isn't the source of the slowdown, unless you have a really huge one.
It could be a part of it, though maybe not a massive part. On my hacked up NAS uboot takes a few seconds to copy the initramfs from onboard NAND into the system RAM before it launches the kernel. If you ditched ramfs you could cut those few seconds out. It's not masses I suppose.... On Tue, Apr 15, 2014 at 5:35 PM, Bill Gatliff <b...@billgatliff.com> wrote: > > On Fri, Apr 11, 2014 at 8:42 AM, David Hicks <d...@nastylittlehorse.net>wrote: > >> I'm not exactly the foremost expert on this but ... my understanding is >> that the initramfs, or initrd or whatever it is, contains a bunch of useful >> things the kernel needs to boot the board fully. Primarily these include >> hardware driver modules needed by the kernel ahead of when the main >> filesystem becomes available. For instance disk controllers and filesystem >> drivers. >> >> One way to reduce the use of the initramfs/initrd is to build a kernel >> that has the drivers you need built into it rather than loaded as modules >> from the ramfs. You would need to build a custom kernel (relatively easy >> with debian already on the device and using make-kpkg) with the kernel >> config customised to achieve this. >> >> I have no idea how much this would speed up boot time, if at all. You >> also lose some of the other benefits of using an initramfs/initrd, which >> I'm having trouble remembering right now. (recovery shell? various scripts >> for mdadm/lve? stuff...) >> > > Actually, baking the necessary modules into the kernel rather than loading > them from initramfs would speed things up quite a bit, especially if the > modules are demand-loaded. Reasons include the fact that you'd be doing > the linking at build-time on your fast PC, rather than at run-time on a > slow(er) ARM core. > > The initramfs isn't the source of the slowdown, unless you have a really > huge one. The bootloader already has to load the kernel, and having the > filesystem in RAM at the same time will usually speed things along. At > least until you have to scour the eMMC to find the final root filesystem, > but there's no avoiding that really... > > Granted, you can put things into initramfs that DO slow you down: hardware > probing, lack of parallelism, sleeps, lots of shell scripts, and so on. > But the initramfs concept itself doesn't present any speed issues. > > I haven't looked at Debian's initramfs lately, since I tend to build my > own. But since Debian favors generalism over performance (as they should), > it wouldn't surprise me to see one built from the ordinary Debian tools > that drags its feet a lot before going to the user prompt. > > > b.g. > -- > Bill Gatliff > b...@billgatliff.com >
