3 simple steps to make booting/shutdown faster...
Behdad Esfahbod
behdad at behdad.org
Sun Feb 17 12:04:11 UTC 2008
On Sat, 2008-02-16 at 18:40 -0800, Arjan van de Ven wrote:
> So I got a tad annoyed by why the initscript processing is (in my impatient perception) slow;
> most initscripts (in timing) only take like 0.1 second themselves after all.
> Turns out.. the rest of the initscript system had quite a bit of overhead.
> (More so on F7 than on F8, but still).
>
> Now... I made a bunch of tweaks to the 3 key files and this made things quite
> a bit faster; F8 is 50% slower than the new situation
> (for a specific test, new code takes 0.275 seconds, F8 code takes 0.41 seconds).
>
> What I changed:
> * if you do if [ -f FOO -o -f BAR ] in bash, bash will look to see if BOTH files exist,
> and then decides that since FOO exits, everything is fine and executes the if body. Looking for non-existing files
> (first time) is expensive.. so splitting this kind of "if" in two reduces disk seeks and IO.
> [this kind of split I had to do in a few places]
This should really be fixed in bash to short-circuit.
> * Don't let the initscripts change the VGA font; after all, this is done during early boot already.
> Programming the VGA fonts is SLOW. (Note: in F7 this was done for each init script, in F8 things were
> a tad, but not much, smarter than that)
I'd go as far as saying that unicode_start should only be called
from /etc/profile, not other bash invocations.
I have a hard time imagining why you hit it at all though, as only
interactive bash should run bashrc which in turn calls
into /etc/profile.d, or am I missing something?
> * Cache the information from /bin/consoletype. this info is used (and calculated with an exec!) all over the place;
> the new code just sticks it in an environment variable. (well it was in one before, just it STILl got recalculated)
> * Check if the service is running before deciding if it's a good service; the common case for "telinit' is that it is and then
> no further file IO on the service needs to be done. (and if it's not we need to check that regardless)
> * cache the value of "the user wants me to ask"; that's not changing so just stick that in a variable rather than looking at
> the file every time. We still do look at the file IF the var is set, because the user might hit continue
> * don't call into "rhgb" if rhgb isn't on the kernel commandline (I have that off on all machines to make them boot faster).
> rhgb got called several times, and isn't cheap, because each time it has to realize rhgb is really not there ;)
> * don't grep each script just to see how to pretty print it; assume a fedora quality script and if not, it's only a tad less pretty
Many moons ago I tried to reduce startup time on my fedora too. I spent
most time on rc.sysinit though. There's a lot that can be optimized
there. I used bootchart to guide my search. In the end I came up with
a short rc.behdad file that I could pass as init to kernel (!) which
would bring up just enough services to start gdm and then pass control
to /sbin/init. And I reached something like 10 seconds from grub to
gdm. I know there's a reason for every line of rc.sysinit, but a huge
lot of it can be optimized or postponed.
There were some plain silly bits. For example look at /sbin/start_udev.
It implements a simple xargs in shell. I remember that took a
measurable amount of time that simply went away by calling real xargs
when available. I guess the __fgrep stuff in functions is supposed to
speed up, but I'm not sure it does so.
There was something really silly with xfs too, but xfs has gone for good
already.
> Attached are the new files that implement these tweaks:
> /etc/rc.d/rc
> /etc/init.d/functions
> /etc/profile.d/lang.sh
>
> I hope others who are as impatient as I am find these tweaks as useful as I do :)
>
> Greetings,
> Arjan van de Ven
Cheers,
--
behdad
http://behdad.org/
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
More information about the fedora-devel-list
mailing list