Init : someone could comment this ?

[nodata]

Am Montag, den 07.01.2008, 12:38 -0500 schrieb Casey Dahlin:
> Les Mikesell wrote:
> > 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 dubious
> >> it 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.
> >
> 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.
> 

So is this frequently loaded binary not being loaded from the disk
cache?