Les Mikesell wrote:
Its not the fork or exec per se. It is the disk IO associated with loading the binary images. Normally this isn't too much of an issue, but in the highly IO-sensitive init process it can cause huge issues. Remember, seek time is the big issue with disk IO, so size of data to load is not the metric to go by.Alan Cox wrote:On Mon, Jan 07, 2008 at 05:35:33AM +0000, Kevin Kofler wrote:AFAIK, busybox still forks whereever a regular POSIX shell forks, so if the amount of forks is the problem, AFAICT busybox will resolve absolutely nothing.Fork should be pretty cheap - although that depends how much memory is unshared by each of the resulting tasks. A smaller cleaner shell such as rc (which was designed for this job in plan 9) or ash might well perform better. I'm dubiousit would be a big difference but someone can bench it.If a unix-like system can't fork/exec at a rate suitable to handle starting it's initial processes you should throw the whole system out and start over, because it will be useless even after you get it running. I think the real problem you need to solve is the number of file opens that happen between boot up and the end of the init script processing. This: http://kernelslacker.livejournal.com/35270.html and the presentation on the topic at Oscon looked pretty horrible and won't be fixed by using a dumber shell to parse the scripts. And note that the suggestion to break out lines of configurations into individual files for easier programmatic editing just compounds this already serious problem.