# gcc-4.1.1 braucht mehr als 700MB Haupspeicher

## bookwood

Ich habe ein Dell Latitude 810C Notebook mit 512MB (mehr geht nicht) Hauptspeicher. Ich nutze auf ihm seit drei Jahren begeistert Gentoo Linux. Ich habe jetzt auf gcc-4.1.1 upgegradet und mit emerge -e [system/world] alles neu kompiliert. Das einzige Packet das nicht mehr durchläuft ist kmail. Es läuft teilweise mehrere Tage und der Laptop swappt sich dum und dämlich. Im Top bekomme ich in der "Virt" Spalte, Werte von über 700 Megabyte angezeigt. Schalte ich den Swap aus stürzt der Kompiliervorgang nach wenigen Minuten mit einer 

```
i686-pc-linux-gnu-g++: Internal error: Killed (program cc1plus)
```

 Medung ab (war scheinlich ist "out of memory" die Ursache). Als Compilerparameter benutze ich 

```
CFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer"
```

 in meiner make.conf.

Jetzt meine Fragen:

Kann ich dem gcc sagen "nimm nicht mehr als 200MB"?

Kann ich in der make.conf nachträglich die Kompiler Optionen ändern (hatte mal gelesen die soll man nicht mehr verändern)?

Kann ich über emerge, nur für kmail, dem gcc sagen nimm "-Os"?

besten Dank im Vorraus

PS: hier noch mein emerge -info

```

Portage 2.1.1 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686)

=================================================================

System uname: 2.6.17-gentoo-r8 i686 Intel(R) Pentium(R) III Mobile CPU      1133MHz

Gentoo Base System version 1.12.5

Last Sync: Fri, 06 Oct 2006 17:00:09 +0000

distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]

ccache version 2.3 [disabled]

app-admin/eselect-compiler: [Not Present]

dev-java/java-config: 1.3.7, 2.0.30

dev-lang/python:     2.3.5-r2, 2.4.3-r4

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     2.3

dev-util/confcache:  0.4.2-r1

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.59-r7

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.13-r4

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.17-r1

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo"

CXXFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict userpriv usersandbox"

GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo"

LINGUAS="de en"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage"

SYNC="rsync://10.1.1.128/gentoo-portage"

USE="3dfx X aac aalib ada apache apm arts avi berkdb bidi bitmap-fonts blender-game browserplugin bzip2 cairo cdda cddb cdio clearcase cli cpudetection crypt cups cvs dga directfb divx4linux dlloader doc dri dts dvd dvdr dvdread elibc_glibc encode esd f77 fbcon ffcall ffmpeg firefox flac foomaticdb fortran gcj gd gdbm ggi gif gimp gimpprint gnome gpm graphviz gtk gtk2 haskell iconv imap imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog java jbig jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kdexdeltas kernel_linux kleptohud lcms ldap libcaca libg++ libwww linguas_de linguas_en lirc lm_sensors lzo mad matroska mikmod mmx mmx2 mod_php motif mozcalendar mozdevelop mozilla mozsvg mpeg multislot nas ncurses netcdf nls nptl nptlonly nsplugin nvidia objc objc++ objc-gc oggvorbis openexr opengl oss pam pascal pcre pdf pdflib perforce perl php pic png postgres postgresql ppds pppd python qt qt3 qt4 quicktime readline reflection ruby sametime scanner sdl session slang spell spl sql ssl subversion svg svga tcltk tcpd tetex theora truetype truetype-fonts type1-fonts udev unicode userland_GNU v4l v4l2 vcd vhosts video_cards_nvidia vlm win32codecs wmf x86 xanim xinerama xml xml2 xmms xorg xprint xscreensaver xv xvid xvmc zlib"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS

```

----------

## mrsteven

Jo, das USE-Flag kdeenablefinal kann sehr viel RAM brauchen. Entweder du schaltest es ab, oder du richtest dir ein Swapfile ein:

```
dd if=/dev/zero of=/var/swapfile bs=1024 count=409600    #ca 400MB

chmod 600 /var/swapfile

mkswap /var/swapfile

swapon /var/swapfile
```

Alternativ kannst du auch eine Swap-Partition erstellen, das erfordert aber ggf. eine Neupartitionierung...  :Wink: 

----------

## moe

Er hast doch eine swap-Partition..

Ja in den CFlags kannst du aus -O2 -Os machen, das einzige was nicht verändert werden darf, ist die Prozessorarchitektur. kdeenablefinal würde ich wirklich in deinem Fall nicht benutzen, mein Standrechner hat 1GB und fängt damit auch beim Kompilieren an zu swappen..

Gruss Maurice

----------

## Carlo

 *bookwood wrote:*   

> Kann ich dem gcc sagen "nimm nicht mehr als 200MB"?

 

Mit 200 MB wirst du KDE nicht bauen können. Und nimm bei dem System bloß kdeenablefinal raus.

 *bookwood wrote:*   

> Kann ich über emerge, nur für kmail, dem gcc sagen nimm "-Os"?

 

Nimm besser -O2 für's ganze System.

----------

## bookwood

Danke Kollegen. 

Das kdeenablefinal Flag hatte ich vor Ewigkeiten aktiviert als ich mit unsermake experimentierte und hatte es dann aus den Augen verloren. Ich habe gerade nochmal danach gesucht und gelesen das dieses Flag unteranderem diesen grossen Speicherverbrauch verursacht. Ich werde es jetzt deaktivieren und nochmal einen "emerge -NDu world" laufen lassen. Das Ergebniss werde ich dann hier Posten. Wenn das auch nicht hilft, baue ich das System mit -O2 neu.

----------

## Anarcho

Eventuell kann man noch RAM während des compilierens sparen wenn du -pipe rausnimmst.

----------

## Fauli

Also hier lässt sich kdepim 3.5.4 mit gcc 4.1.1, CFLAGS="-march=athlon-xp -O3 -fomit-frame-pointer -pipe" und USE="kdeenablefinal" auf 512 MB RAM plus 518 MB Swap ohne Probleme kompilieren.

Du kannst kdeenablefinal ruhig herausnehmen, das Kompilier-Ergebnis ist dasselbe. Es beschleunigt lediglich das Kompilieren, aber natürlich nur dann, wenn dein Rechner nicht deshalb anfängt zu swappen.

Bei kdeenablefinal werden die Quellcode-Dateien eines Unterprojektes aneinandergehängt und dann nur diese eine große Datei kompiliert. Das geht schneller, weil die Header-Dateien in diesem Fall nur einmal gelesen und verarbeitet werden müssen. Aber der GCC braucht zum Kompilieren der riesigen Dateien auch sehr viel Arbeitsspeicher.

----------

## bookwood

Es war das Useflag kdeenablefinal. Nachdem ich es entfernt hatte lief alles sauber durch - auch kmail. kdeenablefinal sollte man also nur mit mehr als einem GB Hauptspeicher verwenden.

----------

## schachti

Naja, 1 GB braucht man nicht, ich habe KDE komplett mit 768 MB kompiliert, ohne daß mein Rechner wild am swappen war.

----------

## energyman76b

naja, hast du eienn amd64 braucht kmail an der einen kritischen Stelle (es sind eigentlich sogar zwei) etwas über 800mb nur für den einen gcc-Prozess.

Was wirklich hilft ist MAKEOPTS="-j1".

Auf einer single-core Maschiene ist jeder höhere Wert sowieso unsinn. Die CPU ist so oder so IMMER ausgelastet.

Wenn man das Kompilieren beschleunigen will, sollte man PORTAGE_NICENESS auf 19 setzen. Klingt komisch, ist aber so. Der Compilierprozess kommt dann zwar nicht so oft dran, aber die Zeit die er hat ist länger - und nicht dauernd den cache und pipelines flushen zu müssen und mal eine 'zeitlang ungestört' zu sein, hilft viel.

----------

## mrsteven

 *energyman76b wrote:*   

> Wenn man das Kompilieren beschleunigen will, sollte man PORTAGE_NICENESS auf 19 setzen. Klingt komisch, ist aber so. Der Compilierprozess kommt dann zwar nicht so oft dran, aber die Zeit die er hat ist länger - und nicht dauernd den cache und pipelines flushen zu müssen und mal eine 'zeitlang ungestört' zu sein, hilft viel.

 

Na ja, mein Buch über Kernel 2.6 sagt aber etwas anderes: Wenn ein Prozess einen hohen nice-Wert hat, dann wird er sowohl seltener gerechnet und er bekommt zudem noch kürzere Zeitscheiben... Es wäre mir neu, wenn die Kernelentwickler das geändert hätten...

Kann es sein, dass du das mit der Unterscheidung zwischen I/O-lastigen und CPU-lastigen Prozessen verwechselst? Ein Prozess, der sich längere Zeit nicht schlafen legt (wie der Compiler), erhält vom Kernel eine kleine Zeitstrafe und wird im Zweifelsfall gegenüber einem Prozess benachteiligt, der gerade frisch erwacht ist...  :Wink: 

----------

## energyman76b

Hi,

nöh, also das letzte, was ich gelesen hatte war, daß Prozesse mit einer hohen niceness zwar seltener drankommen, aber dafür die timeslices länger werden. Also im Endeffekt sich alles ausgleicht.

hmhm

 was ist nun richtig? *kratz*

----------

## bookwood

Ich sprach die ganze Zeit von einem einzelnen GCC Prozess. Bei gesetztem kdeenablefinal wuchs der Speicher auf über 700 MB an und das Kompilieren lief bei mir 2 Tage - bis ich es mit STRG-C abbrach weil ich mit dem Laptop arbeiten musste. Bei ein AMD K8 den ich testweise, mit einer Crossdev Umgebung über distcc zur Hilfe nahm, war der Speicherverbrauch ebenso verherend (über 700MB). Nach dem Entfernen des kdeenablefinal  Useflags lief er, wie schon gesagt, ohne Probleme durch - um 23:00 gestartet - morgens um 6:00 war alles fertig - ohne distcc und ccache - nur auf dem Laptop.

----------

## energyman76b

naja, bei mir läuft kdepim mit kdeenablefinal in 1h8min durch.

Im Durchschnitt...

----------

## mrsteven

 *energyman76b wrote:*   

> Hi,
> 
> nöh, also das letzte, was ich gelesen hatte war, daß Prozesse mit einer hohen niceness zwar seltener drankommen, aber dafür die timeslices länger werden. Also im Endeffekt sich alles ausgleicht.
> 
> hmhm
> ...

 

Deine Quelle? Ich habe das aus dem Linux-Kernel-Handbuch von Robert Love. Wenn sich da seit Kernel 2.6.10 nicht so viel geändert hat, sollte das schon stimmen.  :Wink: 

kdeenablefinal hat auf meinem System mit 512 MB RAM übrigens keine großartige Geschwindigkeitssteigerung zur Folge, wahrscheinlich weil das System oft swappen muss.

----------

## energyman76b

öhm, Quelle ist gut  :Wink: 

war in irgendeiner mail auf gentoo-user. Von einem der gentoo-devs, glaub ich *kratz*

hm,

 - batch scheduling. A significant proportion of computing-intensive tasks

   benefit from batch-scheduling, where timeslices are long and processes

   are roundrobin scheduled. The new scheduler does such batch-scheduling

   of the lowest priority tasks - so nice +19 jobs will get

   'batch-scheduled' automatically. With this scheduler, nice +19 jobs are

   in essence SCHED_IDLE, from an interactiveness point of view.

in /usr/src/linux/Documentation/sched-design.txt

EDIT:

was ich damit sagen will: ich habe wohl einiges falsch verstanden (unter anderem den gentoo-dev) und du hast sicher recht, aber +19 sollte trotzdem helfen.  :Wink: 

----------

## oscarwild

 *energyman76b wrote:*   

> Was wirklich hilft ist MAKEOPTS="-j1".
> 
> Auf einer single-core Maschiene ist jeder höhere Wert sowieso unsinn. Die CPU ist so oder so IMMER ausgelastet.

 

Stimmt nach meiner Erfahrung nicht ganz, die Auslastung liegt mit zwei gcc-Prozessen noch etwas höher, vermutlich weil da ja auch eine ganze Menge Dateioperationen dabei sind. Und während der eine gcc noch auf einen Lese/Schreib-Vorgang wartet, kann der andere compilieren (zumindest erkläre ich mir das so). Bei deutlich mehr Prozessen als Anzahl Cores + 1 bremst man den Rechner aber eher wieder aus.

----------

