Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Jan 2008 01:04:16 -0500
From:      "Aryeh M. Friedman" <aryeh.friedman@gmail.com>
To:        Maxim Khitrov <mkhitrov@gmail.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: speeding up buildworld/kernel
Message-ID:  <47997BE0.5020203@gmail.com>
In-Reply-To: <26ddd1750801242035j3b3cea5ek281fe7e00afbf217@mail.gmail.com>
References:  <4798F1D0.3090009@gmail.com>	 <26ddd1750801241232l51792bf3ydc02e17e4be49d6e@mail.gmail.com>	 <20080124210539.GA50047@owl.midgard.homeip.net>	 <26ddd1750801241408w7b776c87g14b94cfa1433616a@mail.gmail.com>	 <47995F19.7050905@gmail.com> <26ddd1750801242035j3b3cea5ek281fe7e00afbf217@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Maxim Khitrov wrote:
> On Jan 24, 2008 11:01 PM, Aryeh M. Friedman
> <aryeh.friedman@gmail.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>>
>> Maxim Khitrov wrote:
>>> On Jan 24, 2008 4:05 PM, Erik Trulsson <ertr1013@student.uu.se>
>>>  wrote:
>>>> On Thu, Jan 24, 2008 at 03:32:18PM -0500, Maxim Khitrov
>>>> wrote:
>>>>> On Jan 24, 2008 3:15 PM, Aryeh M. Friedman
>>>>> <aryeh.friedman@gmail.com> wrote:
>>>>>> I update my sources at least once a day and do
>>>>>> buildworld/kernel just as often... It seems some stuff
>>>>>> that needs not be recompiled is on every single run for
>>>>>> example gcc and kerbos.   I have NO_CLEAN in
>>>>>> /etc/make.conf is there anything else I can do to speed
>>>>>> stuff up... for ref here is my /etc/make.conf:
>>>>>>
>>>>>> CPUTYPE?=nocona KERNCONF=MONSTER NO_CLEAN= NO_LPR= #
>>>>>> added by use.perl 2008-01-17 11:48:48 PERL_VER=5.8.8
>>>>>> PERL_VERSION=5.8.8
>>>>>>
>>>>>> - -- Aryeh M. Friedman FloSoft Systems, Java Tool
>>>>>> Developers Developer, not business, friendly
>>>>>> http://www.flosoft-systems.com
>>>>> I might be wrong, but NO_CLEAN seems like a bad idea except
>>>>> in special circumstances. Install ccache, but make sure you
>>>>> set CCACHE_HASH_COMPILER environment variable to 1. That
>>>>> will make sure that the cache stays valid if the compiler
>>>>> executable is overwritten by an identical copy (as it would
>>>>> be on installworld). When the compiler changes the cache
>>>>> will be repopulated on the next rebuild.
>>>> You are indeed wrong.  NO_CLEAN will work fine almost all the
>>>>  time - except in special circumstances.  The few times it
>>>> does not work one can always do a 'make clean' by hand first.
>>>> (Or even faster: 'rm -fr /usr/obj/*') If you set WRKDIRPREFIX
>>>> to some useful value you can do the same thing for the ports
>>>> tree. Personally I always compile with -DNO_CLEAN and use 'rm
>>>> -fr' to clean. I have never had problems originating with
>>>> this.
>>>>
>>>> ccache is not very useful for buildworld, since among the
>>>> first thing buildworld does is to build the compiler and then
>>>> use the newly built compiler to compile the rest. I.e. the
>>>> already installed compiler (which is the one ccache will
>>>> handle) will not be used for most of the build thus removing
>>>> almost all the advantage of ccache. It is supposed to be
>>>> possible to use ccache for buildworld as well, but that would
>>>> require a bit of hackery.
>>> That's not true. I just ran `make buildworld buildkernel` on my
>>>  firewall. Here are ccache stats when the operation finished:
>>>
>>> root@cerberus [/root]# ccache -s cache directory /srv/.ccache
>>> cache hit                          12056 cache miss 38 called
>>> for link                      461 multiple source files 1 not a
>>> C/C++ file                    1228 unsupported compiler option
>>> 7 files in cache                    117366 cache size
>>> 679.6 Mbytes max cache size 2.0 Gbytes
>>>
>>> Ccache is used through the entire build process and there is no
>>>  hackery involved. Just follow the directions for changing the
>>> compiler to /usr/local/libexec/ccache/world-cc. On this Celeron
>>> D 1.8 GHz machine rebuilding world and kernel takes 45 minutes
>>> and 40 seconds. I don't recall exactly what it was without
>>> ccache, but I think it was around 3 hours. Just make sure that
>>> you set the CCACHE_HASH_COMPILER variable, otherwise it will
>>> assume that the compiler is different just because its
>>> modification time has changed.
>>>
>>> - Max
>>>
>> No commands where issued on the terminal except the ones showed
>> and ccache was installed with default settings (I didn't modify
>> any files after doing "make install" for ccache)
>
> It doesn't work like that. You have to read
> /usr/local/share/doc/ccache/ccache-howto-freebsd.txt and configure
> things properly before ccache is used for building the os.
>
> In /etc/make.conf you need to add the following:
>
> .if exists(/usr/local/libexec/ccache) && !defined(NOCCACHE) && \
> (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) CC=
> /usr/local/libexec/ccache/world-cc CXX=
> /usr/local/libexec/ccache/world-c++ .endif
>
> Unless you actually want to use /root/.ccache (and have enough
> space for it), I would move that directory to some other partition.
> In my /etc/csh.cshrc I have this configuration:
>
> setenv CCACHE_DIR           /srv/.ccache setenv CCACHE_PATH
> /usr/bin:/usr/local/bin setenv CCACHE_HASH_COMPILER 1
>
> Once you've done all of this, rebuild the world. You can run ccache
> -s during that process. If the hit/miss numbers stay at 0 then
> ccache is not being used. Check your configuration and try again.
>
> The first run will be slower than normal (though not by much),
> because the cache is being populated for the first time. On the
> second run, however, clear ccache stats (ccache -z) and you should
> see the same results as I've posted above. With the exception of
> only a few files, just about everything should be obtained from the
> cache and not compiled from scratch.
>
> - Max
>
Here are the results:

First run (wo/ removing /usr/obj) using the above settings:
119.025u 46.448s 8:11.19 33.6%    487+2711k 15027+6126io 28785pf+0w
flosoft# ccache -s
cache directory                     /usr/.ccache
cache hit                              1
cache miss                             3
called for link                        3
unsupported compiler option            1
files in cache                         6
cache size                           188 Kbytes
max cache size                     976.6 Mbytes

Second run:

I miscopied and pasted before I relized it was wrong and had already
started the next run but from memory:

6:?? minutes (< 6:30)
5 cache hits

I cleaned out /usr/obj /usr/.ccache (where I store the cache) for the
next run:



it crashed:

===> lib/csu/i386-elf (obj,depend,all,install)
rm -f .depend
CC='/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a
- -I/usr/src/lib/csu/i386-elf/../common
- -I/usr/src/lib/csu/i386-elf/../../libc/include
/usr/src/lib/csu/i386-elf/crt1.c /usr/src/lib/csu/i386-elf/crti.S
/usr/src/lib/csu/i386-elf/crtn.S
/usr/local/libexec/ccache/world-cc -O2 -fno-strict-aliasing -pipe
- -I/usr/src/lib/csu/i386-elf/../common
- -I/usr/src/lib/csu/i386-elf/../../libc/include -Wsystem-headers
- -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
- -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
- -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align
- -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs
- -Wredundant-decls -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1.c
{standard input}: Assembler messages:
{standard input}:27: Error: suffix or operands invalid for `mov'
*** Error code 1

Stop in /usr/src/lib/csu/i386-elf.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
1713.072u 279.765s 58:14.38 57.0%    6179+8423k 22605+12323io 8667pf+0w

- --
Aryeh M. Friedman
FloSoft Systems, Java Tool Developers
Developer, not business, friendly
http://www.flosoft-systems.com

    "Free software != Free beer"

Blog:
 
http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmXvgQi2hk2LEXBARAohlAJ4kFVb/o7pHN2Q551n4iDMFhpprGwCbBkUe
p5hwkE6sGOkpYEP7Taq+tM0=
=llvM
-----END PGP SIGNATURE-----




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47997BE0.5020203>