From Electron Cloud
Jump to: navigation, search
(New page: I'm evaluating upstart, init-ng, runit etc. Another idea I thought of along the way: It has been pointed out that booting is mostly IO-bound. Why is restoring from hibernation so fast? ...)
 
Line 1: Line 1:
 
I'm evaluating upstart, init-ng, runit etc.  Another idea I thought of along the way:
 
I'm evaluating upstart, init-ng, runit etc.  Another idea I thought of along the way:
  
It has been pointed out that booting is mostly IO-bound.  Why is restoring from hibernation so fast?  Because probably it's one contiguous block being loaded from disk into memory.  So how about trying to somehow cause the boot process to load code into memory from contiguous disk blocks, in the order that the boot process needs the programs to be loaded?
+
It has been pointed out (and is obvious in the last 2/3 or so of most bootcharts) that booting is mostly IO-bound.  Why is restoring from hibernation so fast?  Because probably it's one contiguous block being loaded from disk into memory.  So how about trying to somehow cause the boot process to load code into memory from contiguous disk blocks, in the order that the boot process needs the programs to be loaded?
  
 
I think this idea could be independent of the version of init or its replacement.
 
I think this idea could be independent of the version of init or its replacement.

Revision as of 14:33, 20 October 2007

I'm evaluating upstart, init-ng, runit etc. Another idea I thought of along the way:

It has been pointed out (and is obvious in the last 2/3 or so of most bootcharts) that booting is mostly IO-bound. Why is restoring from hibernation so fast? Because probably it's one contiguous block being loaded from disk into memory. So how about trying to somehow cause the boot process to load code into memory from contiguous disk blocks, in the order that the boot process needs the programs to be loaded?

I think this idea could be independent of the version of init or its replacement.

You simply need to make a log of the files that are loaded. Then after booting is complete, make a tarball with those files, in the order that they were necessary. Write an init wrapper which forks off a process (or a thread even) to untar the tarball and "seed" the cache with those files. (I hope there is a system call for that?) Then when enough files have been seeded into the cache for init to begin, start it. Each file that the init process needs will have already been loaded into cache, so the kernel will not need to read from the physical disk in order to satisfy anything which init is running. The other thread or process keeps running in the background, anticipating the next file that init will need.

Because booting this way might change the order that files are needed, after each boot the tarball should be rebuilt (in the background of course, with a high value of "nice", maybe even delayed a few minutes so the user has a chance to start doing something useful first).

If you are using a parallel version of init, it doesn't make much difference - the files might be needed in a different order but we are optimizing the tarball order each time, so equilibrium should be reached quickly. If it becomes static (the order that files are needed is the same as the tarball order) there is no need to rebuild the tarball anymore.