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