[gentoo-dev] rc-scripts speedup

[gentoo-dev] rc-scripts speedup

[leon j. breedt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi guys,

i did a change to rc-scripts to force GNU grep/gawk to use C
locale at startup, which is fine since config is ASCII.

red hat 9 does this, and from the noticeable startup speed
improvement i saw there, i guessed that the same would apply
in Gentoo, since Gentoo uses the same versions of grep/gawk.

and for me, at least, it felt noticeably faster on startup and
reboot with the change.

i've created an enhancement request:

http://bugs.gentoo.org/show_bug.cgi?id=19598

please check it out if you feel like testing this, it shouldn't
break your system, all it does is prefix awk/grep invocations
in a few /sbin and /etc/init.d scripts with LC_ALL=C.

to test, just hack your baselayout ebuild to use the
later version of rc-scripts that i have attached in the report,
and remerge.

i want to know if anyone else experiences a speedup...

leon

- -- 
in the beginning, was the code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+oSuRRWcl5mzp4f4RAklRAJ9Iqgp3ZPG180N3oJRgwCWW+GihbgCfVUKj
1OOYa4C8vfZly28UgKUyhE4=
=GsAJ
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] rc-scripts speedup

[leon j. breedt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 19, 2003 at 11:26:16AM -0700, Eric Andresen wrote:
> Whoops, I was posting from the wrong address.
> 
> Two things.. using a few methods of making LC_ALL=C for grep/awk only,
> none of them had any significant change in startup time one way or the
> other.
> 
> Second, wouldn't it be a lot easier to just alias grep and awk to
> "LC_ALL=C grep" and likewise for awk within runscript.sh?
well, i went for the all-out approach, and replaced every invocation
with LC_ALL=C <cmd>, and did the export LC_ALL=C before all occurences
of "x start|stop". it felt a bit faster..i'm going to revert to the
existing rc-scripts and see if i can feel a difference.

have you tried using the rc-scripts i attached to the bug report?

i don't think just exporting LC_ALL=C in just one place is sufficient, i'm
sure it gets dropped on the floor a few times.

also, will an alias be inherited by everything thats executed down the
line?

leon

- -- 
in the beginning, was the code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+oew1RWcl5mzp4f4RAphEAJ0QU/cF2yG8DL5s2BoEVWcUYw2XagCeMv3m
Tg/7SqGpWaVaflTTLWO/PW8=
=L6VK
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] rc-scripts speedup - or not :/

[leon j. breedt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Apr 20, 2003 at 12:39:17PM +1200, leon j. breedt wrote:
> well, i went for the all-out approach, and replaced every invocation
> with LC_ALL=C <cmd>, and did the export LC_ALL=C before all occurences
> of "x start|stop". it felt a bit faster..i'm going to revert to the
> existing rc-scripts and see if i can feel a difference.
okay, its bad form to reply to your own posts...but i did some very crappy
benchmarking (cat /proc/uptime >/tmp/boottime in /etc/conf.d/local.start),
and booted each set of rc-scripts 10 times.

results inconclusive...sometimes LC_ALL=C booted faster, sometimes without
did. and with either enabled, boot times would fluctuate between 17 and
15.9 seconds for a full boot, no clear win with LC_ALL=C enabled.

i did some more research, and it seems this hack is necessary on Red Hat
because they set LANG to a UTF locale on bootup. something which Gentoo
doesn't do. at least, a grep for LANG in /etc turned up nothing.

unless grep/awk default to a UTF locale in the absence of LANG,
it seems Gentoo is already as fast as it can be in this regard. 

i think a note should be made if Gentoo at some point in the
is going to set LANG, though.

sorry about blowing smoke...i think i just witnessed one of faster bootups
after changing to LC_ALL=C. this will teach me...

leon

- -- 
in the beginning, was the code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+oiorRWcl5mzp4f4RAvshAJ0SR/gF1HN9bZ9xRMyxmJ2iihlCogCgtsMK
uQ8auRfK4rLS+p7TQEQQug8=
=QTVk
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] rc-scripts speedup - or not :/

[Joseph Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Apr 20, 2003 at 05:03:39PM +1200, leon j. breedt wrote:
> sorry about blowing smoke...i think i just witnessed one of faster bootups
> after changing to LC_ALL=C. this will teach me...

I have gotten fast booting of a Gentoo box nearly down to a science at
this point.  ;)  Setting LC_ALL=C is not something I've done yet.

I have a notebook which lacks APM and found swsuspend unstable.


My assumption was that there were core things which must be done before I
login to the system, and anything else could be done behind the scenes.  I
have actually speculated that it is probably safe to build a config which
does little more than mounting filesystems, bringing up lo, and starting a
display manager.  I'm not that far along yet.  Here's what I have done so
far:

My kernel has everything built as modules which can be, but it still takes
too long to boot.  (Before I modularised everything, the kernel itself
took 14 seconds, now it's about 10 seconds..)  I do not know how to make
it any faster to boot.  Tips here are welcome.  Keep in mind I am not
looking for the "feel" of being fast.  I'm doing this with a stopwatch.

Runlevel boot contains bootmisc, checkroot, clock, hostname, localmount,
modules, net.lo, rmnoilogin, and urandom.  I've modified modules to simply
perform the modprobing in the background, and I do not bother to print out
the eend for the notices of module loading.  Everything else normally in
boot was removed because I don't need it.

Runlevel default has been totally gutted.  It contains metalog and extra,
that is all.  I'm not sure metalog will not be removed soon.

Runlevel extra is interesting.  Here is /etc/init.d/extra:

#! /sbin/runscript

depend() {
	after *
}

start() {
	/sbin/telinit b &>/dev/null &
}


The things that actually live in runlevel extra are cupsd, gpm, ifplugd,
local, metalog, and pcmcia.  The inittab line basically starts this in the
background with output sent to the bitbucket.

It still takes a significant amount of time for the services to all start,
but they need not be running at that point, so I don't have to care.


Before I began this effort, I found two problems.  First, as soon as the
e100 module was loaded, hotplug would be intelligent enough to try and
load the damned network script.  Absolutely brilliant, given that it's a
laptop, the ethernet connector is permanently affixed, that net.eth0 does
not as Gentoo provides it support anything more intelligent than dhcpcd,
and that I almost never plug in an ethernet cable unless I'm leeching.  I
have ifplugd to handle this interface.

Why is this significant?  It added several seconds to the boot sequence as
runlevel 3 tried to down eth0, which meant letting dhcpcd sit there for as
much as ten seconds attempting to commit suicide.  I spent nearly an hour
trying to figure out how it was getting started, and modified net.agent to
treat eth0 as an assumed preconfigured interface.  Some mechanism to tell
hotplug to not try to configure certain interfaces other than editing bash
scripts would be nice.

Another error which was pre-existing and never isolated is this:

insmod: insmod: a module named usbcore already exists
insmod: insmod: insmod
/lib/modules/2.4.20-acpi-r9/kernel/drivers/usb/usbcore.o failed
insmod: insmod: insmod usbcore failed

I cannot find what is attempting to insmod usbcore.  In fact, I cannot
find any scripts which call insmod at all in /etc or in /sbin.  hotplug's
usb-agent will try to modprobe it, but that's not an issue really since
modprobe would deal sanely.  I am considering that I might want to modify
init.d/modules to modprobe certain things at boot time and certain other
things in extra.

I guess it might work to grab the most current initscripts, but my
notebook is a machine which really should not be compiling all the time,
so I've been hesitant to run ~x86 when not necessary.  Doesn't seem to
matter though, /sbin/rc is basically the same as on my notebook and that
is probably where further optimisations would be made.

I welcome assistance, a clue where the above insmod error is from, and a
suggestions as to how to get the boot under 17 seconds.  This is down from
24, but I am aiming for less still.  (I note that booting Debian used to
take over a minute on my notebook..)

- -- 
Joseph Carter <knghtbrd@efn.org>                      This end upside-down
 
"Nvidia's OpenGL drivers are my "gold standard", and it has been quite a
while since I have had to report a problem to them, and even their brand
new extensions work as documented the first time I try them.  When I have
a problem on an Nvidia, I assume that it is my fault.  With anyone else's
drivers, I assume it is their fault.  This has turned out correct almost
all the time."
        -- John Carmack
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: 1024D/20F62261F1857A3E79FC44F98FF7D7A3DCF9DAB3

iEYEARECAAYFAj6iWDYACgkQj/fXo9z52rPUWgCeLyIne2AvXyhy+rBAl60ZNl3e
VSMAn0hfI4plMCdWSyGYROlLOkz1fXTV
=69Ch
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list