[HOWTO] Flying with gentoo

[twiggy]

http://217.209.205.126/goawaybaselayout.html

I hope this could be of any use for some of you

How does this speed anything up exactly?

Reduces the bootup time alot. It might not be what you want but it is without a doubt in the speed category.

[Hackeron]

Reduces the bootup time alot. It might not be what you want but it is without a doubt in the speed category.

Well, I just tried it on a spare machine that I use for distro testing, and I dont notice any speed up what so ever. Maybe its there, especially if you have many services, but then again you already have parallel startup in baselayout and there's ofcourse tips on this thread to make startup as fast as possible. Try them!

Even if there is a slight gain in speed if using sysvinit with those scripts instead of baselayout (no gain in speed here), I dont see how anyone would compromise baselayout's usability for it.

The init system in gentoo is one of my favorite things about the distribution. Look at fedora's sysv implementation - services marked started when they're not is just one of the examples of the many things wrong with it - and they have a far more advanced configuration than crux

[twiggy]

It's all about taste

Baselayout might be useable but i just hate it. Mostly because the output is so freaking ugly and i like to keep things simple.. It's certainly not something everyone should use but it's perfect for me..

[Hackeron]

It's all about taste

Baselayout might be useable but i just hate it. Mostly because the output is so freaking ugly and i like to keep things simple.. It's certainly not something everyone should use but it's perfect for me..

Ofcourse, very valuable howto! , I just think it deserves its own thread on the documentation forum!

Afterall, gentoo is about choice

[twiggy]

It's all about taste

Baselayout might be useable but i just hate it. Mostly because the output is so freaking ugly and i like to keep things simple.. It's certainly not something everyone should use but it's perfect for me..

Ofcourse, very valuable howto! , I just think it deserves its own thread on the documentation forum!

Afterall, gentoo is about choice

http://forums.gentoo.org/viewtopic.php? ... 75#1665175
If you'd like to say hello or whatever

[bruciemoose]

I'm a newbie to Gentoo, but I would have thought that hdparm would be best run as soon as possible. Looking at /etc/init.d/hdparm the dependency shows:

Code: Select all

depend() {
        before bootmisc
}

Since bootmisc is in the "boot" runlevel, I would assume that it would be best to run hdparm in "boot" and not "default"?

Andrew

[asph]

bruciemoose: if you want to run hdparm the soon as possible put it on the boot runlevel (which is executed before the default one)

twiggy: the baselayout tweaks look amazing, but also it seems dangerous when you lose all the improvements/fixes/changes made in the new baselayouts gentoo releases.. maybe i would go with modyfing it, instead of unmerging it all

[twiggy]

bruciemoose: if you want to run hdparm the soon as possible put it on the boot runlevel (which is executed before the default one)

twiggy: the baselayout tweaks look amazing, but also it seems dangerous when you lose all the improvements/fixes/changes made in the new baselayouts gentoo releases.. maybe i would go with modyfing it, instead of unmerging it all

I tweaked baselayout a bit before but it's a lot easier to get the things like you want it by starting from scratch.. the only real "downside" i can see is you really can't tell if all the initscripts gets up and running or if it fails but i really don't care that much and it's problably not so hard do fix that..

[Kurse]

Keffin,
Thanks for the input. Seeing as how you have not actually tried this, could you elaborate a little on your basis for thinking they are compatible, or point me to some info (other than the forum threads)?

I recently installed Yoper on one of my boxes, and it has prelink out of the box, and I must say Yoper is very snappy for a precompiled rpm distro. Therefore, I prelinked one of my Gentoo installations to see if made any difference. I have to say I can barely notice any, and maybe I'm imagining any perceived improvement.

Then I read about LDFLAGS, and it seemed like something to try, thus my question about prelink & LDFLAGS. Can anyone confirm that I remove prelink before trying LDFLAGS, or doesn't it really matter?

My system is prelinked, and I do use LDFLAGS as well. I havent had any negative impact that I can see, and I do notice a speed improvement with some applications

[pennedinil]

My Experiences with LDFLAGS

I thought I'd add this to the post. Perhaps someone can confirm/correct my problems.

In the hopes of maximizing speed and optimizing my system, I added the following to make.conf -

Code: Select all

CFLAGS="-O2 -pipe -march=pentium4 -fomit-frame-pointer"
CFLAGS=" -maccumulate-outgoing-args -ftracer" #<-- additional opts
CFLAGS+=" -mmmx -msse -msse2" #<-- for the extra registers
CFLAGS+=" -mfpmath=sse" #<-- for my math libs
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,-s"
CFLAGS="$CFLAGS $LDFLAGS" #<-- gives lots of gcc warnings but works
CXXFLAGS="$CFLAGS -fvisibility-inlines-hidden"

I felt adding LDFLAGS to CFLAGS would force those packages that do not otherwise use LDFLAGS to do so.

I'm using hardened toolchain, with gcc-3.4.2 with the latest glibc libs, system compiled from the ground up.

One of the strangeness I noticed was that some of the executables now had the suffix "*.c.20.combine". This was especially noticable in the star & cdrtools packages. Other packages exhibiting this behavior are pkgconfig, gdb and xterm. I had to manually go into the PORTAGE_TMPDIR and rename the files for the application to complete the merge.

Other applications also give similar problems, I can't remember exactly which ones, but the fix usually involved me having to manually rename files or move them around in PORTAGE_TMPDIR.

Another problem I noticed was when kdelibs failed to compile. After a lot of backtracking, I found that the problem was with the jpeg package. With LDFLAGS in CFLAGS, libjpeg.so is not created. Which is very odd. [Perhaps this sould be in a bug report.]

All said and done, I feel my system is now a lot more responsive. E.g., konqueror opens immediately instead of the normal 2-3 second delay.

So my questions here are -
1) anyone else try the above?
2) if so (or even otherwise) anyone else notice anything similar with cdrtools?
3) what about the jpeg package?
4) if you haven't tried this, would anyone else be willing to confirm the above, just so I know it's not specific to my system?

Thanks.

And BTW pretty good HOWTO, somet things I really like, others I'm not yet ready to embrace.

[twiggy]

mvila:

In the updated version of my guide and i've removed the part where you remove baselayout so that can't cause any problems and otherwise the init stuff works like in the old guide..

[xces]

@pennedinil:

Code: Select all

CFLAGS="-O2 -pipe -march=pentium4 -fomit-frame-pointer"

-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't
need one. This avoids the instructions to save, set up and restore
frame pointers; it also makes an extra register available in many
functions. It also makes debugging impossible on some machines.

[...]

Enabled at levels -O, -O2, -O3, -Os

-fomit-frame-pointer is already activated, when you use -O2.

Code: Select all

CFLAGS=" -maccumulate-outgoing-args -ftracer" #<-- additional opts

You are lacking a '+' here, aren't you? The compiler-flags you added here both make the size of the generated code bigger, so you should have a quite fast harddisk to compensate this.

Code: Select all

CFLAGS+=" -mmmx -msse -msse2" #<-- for the extra registers

All three flags/features are already activated when using -march=pentium4.

[pennedinil]

You're right about the missing + in my CFLAGS. Typo when I typed out the post.

I saw something similar about -fomit-frame-pointer somewhere, that it's activated with -O2. But I've also seen something to the converse. So just to be safe, I leave it in.

And I've seen something similar with regard to -mmmx -msse -msse2, that they are not activated by default with -march=pentium4, so again, just to be on the safe side...

It's more than possible the x86-P4 relevant flags above are activated with -march, and perhaps what I read was in reference to -mcpu.

And yes, I do have more than enough disk space. Compared to the amount of space the portage tree takes up (packages, distfiles, tempfiles, ebuilds, ccache), which adds up to about 30GB (yes, I don't clean house often!) the added size of the executables is something I'm very much willing to live with.

This still doesn't answer my other questions though...

Thanks.

[M@rijn]

Here a little question, how can i set prelink as een startup service, so he starts up with the system?

[pleusicles]

Here a little question, how can i set prelink as een startup service, so he starts up with the system?

You can't (and don't have to). After prelinkink, the effect will last as long as binaries aren't changed. But you will need to re-run prelink when emerging new versions. You may, however, make a cron job which does that regularly for you.

[ahorn]

Hi there,
got some tiny problems by compiling glibc with nptl and prelink with normal use flags

Code: Select all

[blocks B     ] sys-kernel/linux-headers (from pkg sys-kernel/linux26-headers-2.6.8.1-r1)
[ebuild  N    ] sys-kernel/linux-headers-2.4.22  -build 28,836 kB
[ebuild  N    ] sys-kernel/linux26-headers-2.6.8.1-r1  -build 34,793 kB
[ebuild   R   ] sys-libs/glibc-2.3.4.20040808-r1  -build -debug -erandom -hardened -makecheck -multilib +nls +nptl* -pic -userlocales 0 kB

Code: Select all

[blocks B     ] dev-libs/libelf (from pkg dev-libs/elfutils-0.94-r1)
[blocks B     ] dev-libs/libelf (from pkg sys-devel/prelink-20040707)
[ebuild  N    ] dev-libs/elfutils-0.94-r1
[ebuild  N    ] sys-devel/prelink-20040707

both blocks are still there with ~x86! i use 2.6.9-r4-love1

can you give me any explanation how i can manage this? the other tweaks works well. for amd users i recommend to use athcool. a nice tool, cools the cpu by increase the powersaving feature so you can oc them more

[bob1977]

For glibc, I think you have to inject linux26-headers somewhere. Try to search in forums for glibc and nptl.

For prelink, you must unmerge libef and then you will emerge prelink. Finally you type: prelink -avmR. Wait for 20 minutes and it's done. I've just installed it and I'm going to test the new performances.
See you later.

[ahorn]

thanks for the tip at prelink

Code: Select all

checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.

!!! ERROR: dev-libs/elfutils-0.94-r1 failed.

i'm going to unpack gcc glibc binaries to fix this prob. maybe i've got broken linux-headers or i need libelf to let gcc work

@nptl: --inject is deprecated by portage, i guess. and i don't wanna mess with glibc by doing handstuff. is there not an easy routine to get nptl working?

[iainvt]

fantastic tips man

[baeksu]

Tried adding xdm (i.e. gdm) to my boot run-level, works with no problems.

acpid | battery default
alsasound | battery default
aumix |
bootmisc | boot
checkfs | boot
checkroot | boot
clock | boot
consolefont | boot
cpufreqd |
crypto-loop |
cupsd |
domainname |
esound |
famd |
gkrellmd |
gpm |
hdparm |
hostname | boot
hotplug |
iptables |
keymaps | boot
local | battery default nonetwork
localmount | boot
metalog | battery default
mit-krb5kadmind |
mit-krb5kdc |
modules | boot
mpd |
net.eth0 |
net.lo | boot
net.ppp0 |
net.wlan0 |
netmount |
nscd |
numlock |
portmap |
rmnologin | boot
rsyncd |
serial | boot
slmodem |
speedfreq | default
splash |
sshd |
urandom | boot
xdm | battery boot
xfs |
xprint |

I'm not familiar with the runlevels or depenencies, however. Xdm kicks in at the end of the boot levels, and as I have little on my default level, the speed increase is not very huge. Still, X starts a little earlier than before.


On a another note, there's some discussion on using the suspend/hibernate to speed up starting the computers.

http://forums.gentoo.org/viewtopic.php? ... 15#1679415

I haven't had time to try it myself yet, but will do as soon as I get around installing the suspend scripts.

[nat]

In this section I just wanted to mention some things that can help us.
First of all, if you have two harddisks it is better to put the swap partition on the second disk (having the root partition in the first one) as this will improve the read/write times.

Wouldn't it be better to have 2 swap partitions, one on every IDE bus? Linux is supposed to automatically RAID swap, so using 1 swap on every disk (on different IDE busses) would almost double the swap speed in theory.

Correct me if I am wrong. I have not tested...

And about CFLAGS, I suspect that bigger C++ applications (like KDE) will go faster with -Os instead of -O3. That is also theory, but if the main bottle neck is the disk, it is probably true. I believe this might be noticeable on slower boxes.

[nat]

One more interesting thing could be nscd, or Name Service Cache Daemon. Should give faster web since it doesn't have to do a DNS lookup for visited URLs.

Since I am maintaing a DNS proxy I had to compare nscd with dnrd.

Code: Select all

ncopa@nc ~/src/stressdns $ sudo /etc/init.d/nscd start
 * Starting Name Service Cache Daemon ...                                 [ ok ]
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26247: 9986 of 10000 lookups was successful. Time: 8.770 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26248: 9986 of 10000 lookups was successful. Time: 1.297 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26249: 9986 of 10000 lookups was successful. Time: 1.225 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26250: 9986 of 10000 lookups was successful. Time: 1.168 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26251: 9986 of 10000 lookups was successful. Time: 1.529 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26252: 9986 of 10000 lookups was successful. Time: 1.334 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26253: 9986 of 10000 lookups was successful. Time: 1.803 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26254: 9986 of 10000 lookups was successful. Time: 1.346 seconds

stressdns is a small utility I wrote to test a bunch of gethostbyname calls. In this example I did lookups of 10000 names from a squid log.

The first run is slow (8.7 seconds) because the cache is empty. The next runs are fast.

I started modified /etc/conf.d/dnrd to point to y DNS servers, modified /etc/resolv.conf to point to 127.0.0.1 and started dnrd.

Code: Select all

ncopa@nc ~/src/stressdns $ sudo /etc/init.d/dnrd start
 * Starting dnrd ...                                                      [ ok ]
ncopa@nc ~/src/stressdns $ sudo vim /etc/resolv.conf 
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26439: 9986 of 10000 lookups was successful. Time: 2.330 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26440: 9986 of 10000 lookups was successful. Time: 0.838 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26441: 9986 of 10000 lookups was successful. Time: 0.854 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26442: 9986 of 10000 lookups was successful. Time: 0.841 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26443: 9986 of 10000 lookups was successful. Time: 0.830 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26444: 9986 of 10000 lookups was successful. Time: 0.838 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26445: 9986 of 10000 lookups was successful. Time: 0.834 seconds

Without nscd and dnrd:

Code: Select all

ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26405: 9986 of 10000 lookups was successful. Time: 6.391 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26406: 9986 of 10000 lookups was successful. Time: 5.365 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26407: 9986 of 10000 lookups was successful. Time: 5.212 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a 
Number of parallell lookups: 1
26408: 9986 of 10000 lookups was successful. Time: 5.463 seconds

(pretty fast lookups anyway because I run a bind on a P4 with gigabit....)

Conclusion is: dnrd is the fastest here. You will ofcourse not note any difference unless you do some really heavy DNS intesive things, but dnrd adds security by randomizing the UDP source ports.

So I recommend dnrd (http://dnrd.sourceforge.net) instead of nscd.

Unfortunally it is not in the portage tree yet, even if an ebuild have been around for a long time.
http://bugs.gentoo.org/show_bug.cgi?id=56378

[Dana Merrick]

Tried adding xdm (i.e. gdm) to my boot run-level, works with no problems.
...I'm not familiar with the runlevels or depenencies, however. Xdm kicks in at the end of the boot levels, and as I have little on my default level, the speed increase is not very huge. Still, X starts a little earlier than before.

I did the same thing, and it's a subtle improvement.
Does anyone know what the deps are for xdm?
I feel that it could be booting faster than it is, but I'm not sure what else I need to start...

(Edited to fix quote tags )

[rhill]

-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't
need one. This avoids the instructions to save, set up and restore
frame pointers; it also makes an extra register available in many
functions. It also makes debugging impossible on some machines.

Enabled at levels -O, -O2, -O3, -Os

-fomit-frame-pointer is already activated, when you use -O2.

but if you look further up, it states:

-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.

the x86 architecture is definitely one of the ones where it makes debugging impossible, and so it is not activated at any -O level unless it's stated specifically.

i wish i had a better reference, (of course you can't find these things when you need them)
but this recent post backs it up:

http://lists.gnu.org/archive/html/gcl-d ... 00005.html

Test configuration 1.

With optimisation set to "-g -O3" (that is, without -fomit-frame-pointers)


maxima ignore-errors -- NO

"universe.lisp" -- NO

Test configuration 2.

With optimisation set to "-g -O3 -fomit-frame-pointers":

maxima ignore-errors -- NO

"universe.lisp" -- FAIL

--de.

[HardenCoonor]

LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,-s"

I think with binutils-2.15.92.0-* -Wl,--enable-new-dtags is obsolete, as it is most probably activated by default, there is a patch included in the binutils-patch-tar.bz2.

Has anyone tried -fdata-sections and/or -ffunction-sections in his/her CFLAGS and -gc-sections in LDFLAGS?