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? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
